Thanks so much for the detailed reply. I'm slowly but surely wrapping my head around everything.
On Tue, Jul 18, 2023 at 10:35 AM Daniele Nicolodi <[email protected]> wrote: > [...] > There are two modalities in which you can operate, distinguished by what > you define to be the "source of truth": > > 1. you have the source of truth to be the input files for your > importers, and that the importers are "smart" enough to generate a > Beancont ledger with all the information you need for further > processing. In this case, you don't need to worry about mixing manual > and automated steps: you can regenerate your ledger from the input files > at any time. > > 2. you can have the Beancount ledger to be the source of truth, and the > importers are meant to produce a ledger that you manually edit. For this > use case, the importers framework have support for this use case via the > deduplication system: it uses some fuzzy matching between transactions > to identify transactions in the imported batch that are already in your > ledger. > Yes, this is a good framing. (2) makes sense for a lot of use cases, but I was aiming for something more like (1). But we'll see, I can experiment with both. What you seem to be after is a way to update the ledger entries with new > infomartion (either by running an improved version of the importers or > by combining information from different sources). This is possible, but > Beancount does not offer any facility for this. The main reason is that > the logic for merging or updating the ledger entries the core of the > problem and it cannot be generalized. However, the "boring" code around > the problem is readily available: you can easily parse a Beancount > ledger, modify it, and serialize it back into an human readable ledger, > see the beancount.parser.parser and beancount.paerser.printer modules. > The only drawback in doing so is that the Beancount parser does nor > preserve whitespace and comments, thus you loose these when you go > through this process. The autobean.refactor project should solve the > issue, but I haven't had occasion to try it yet. > Makes sense. I think for me it may depend on how diverse the manual tweaks are -- if they're diverse, then as you say it's impractical to generalize them. If there are a small number of regular ones in my limited domain, then I may be able to use a simple declarative language to specify the tweaks to be applied automatically. > I can snapshot the beancount inputs, and I can snapshot the beancount > > outputs, but what I am trying to understand is if there's a way to turn > > the beancount outputs (its choice of lot matching) around and use them > > as inputs (specified lot matches) next year. > > I don't understand what you are asking. The automated lot matching is > not stored anywhere thus you cannot "reuse" it when you change the tot > algorithm. Well, that was what I was asking -- is there a way to do that, and you have answered "no" :) > However, the automated lot matching algorithm is only a > convenience: you don't need to use it and always specify lots manually. > > Specifying the lots explicitly is the easiest solution if you want some > "non-standard" lot matching or you want the lot matching to change over > time. More complex solutions may involve plugins to augment the > transaction read from your ledger with lot information computed with > some arbitrary algorithm. > I have way too many transactions to manually assign lots. But simple HIFO/FIFO across all accounts and all time is not sufficient (if it were, I'd just use one of the many online services for computing cap gains). I need a way to experiment with lot selection algorithms, then when I find one satisfactory enough to use it to file my taxes, "freeze" those lot selections so that future experimentation doesn't change selections that have already been reported to the IRS. Since Beancount already does the computation to match lots, and since it also provides a language for specifying manually matched lots, it seems like it could be not that difficult to extend Beancount with the functionality to emit its lot-matching decisions using the lot-matching features of the language. Does this seem reasonable? If so, I can look into how this might be done... I'm a little surprised this doesn't seem to be a more common problem; I would think this would be useful to many traders. thanks again, eric -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFXPr0tCfzkXdZKCCs46k4u2BCU8cL%3DX69QKOdas5Ji-ndzezg%40mail.gmail.com.
