On Wed, Aug 21, 2024, 17:34 Eric Altendorf <[email protected]> wrote:
> Thanks, makes sense. > > Re-serializing the data structures after parsing/booking seems > reasonable. That's not something Beancount currently can do, is it? > Not in there nice way I envision. You could sort of hack by finding the locations of the cost basis inputs using the metadata stored on the parser directives (which are close to an ast) and insert they missing cost basis as strings. Ugly. Aside from the comments issue, it seems this shouldn't in principle be > difficult to do? > I wouldn't call it difficult but the parser's output has to be extended to store all of the comments and whitespace in between the stuff that matters. > Since my pipeline is mostly automated I haven't been using comments > (instead putting extra info in metadata tags for the code to read) so I > don't mind comments being lost. > I suspect most people do a nontrivial amount of writing their beancount file by hand. > On Tue, Aug 20, 2024 at 11:28 PM Martin Blais <[email protected]> wrote: > >> On Wed, Aug 21, 2024, 00:51 Eric Altendorf <[email protected]> >> wrote: >> >>> I'm struggling to come up with the right workflow for filing capital >>> gains taxes each year. >>> >> >>> I have too many lots for manual lot selection to be feasible, so I rely >>> on automatic booking. However, the method I picked when I started filing >>> my taxes a few years ago may no longer be what I want to use. >>> >>> One option would be to run parsing and booking for the older >>> transactions, and somehow persist the booking decisions. AFAIK, this isn't >>> currently possible with Beancount but it doesn't seem too difficult in >>> practice. >>> >> >> I think if you bake in all the cost basis numbers explicitly the booking >> method doesn't get invoked. It's only there you resolve closing postings >> with a missing cost basis. In that way if you replaced your inputs to have >> an explicit cost basis you can cement the old decisions (which I think you >> have to, because they've been declared to the irs) >> >> >> >> >>> Another option would be to create sub-accounts for each account, per >>> year (or whatever time period), since then I can assign per-account booking >>> methods for each year. This doesn't require any changes to Beancount, but >>> it makes my accounts messier and requires synthetic transfers from one >>> year's account to the next. >>> >> >> Agreed, that's a bit ugly. Better might be too define your own booking >> method, that is dependent on time. That would require changing beancount to >> at least allow registering custom booking methods or to extend its default >> way to specify them by adding date ranges where they're applied. I'm not >> against it in principle but it's unclear if the additional complexity is >> worth it. >> >> >>> Finally, another option is to implement a new virtual booking method >>> that dispatches to a particular booking method based on the date of the >>> transaction. This is kind of easiest but seems the ugliest. >>> >> >> I wrote my answer above before I read this paragraph and it sounds like >> the same idea. I think that is the most elegant, because it reflects what >> were trying to do accurately: change the booking method over time. >> >> If it was easy to rewrite the input to insert the cost basis numbers that >> would be the nicest solution imho because you wouldn't have to maintain >> older versions of algorithms. Imagine for example a case where there was a >> bug in the booking method and you declared these amounts to the irs. It >> wouldnt be great to have to maintain the buggy code to be reapplied >> historically. This is why I think in a new parser we want to treat the >> input a little more like a database with update capability, where we can >> parse, make some modifications - insert the cost basis - and produce a new >> file with them changes but that otherwise keeps everything else the same >> including comments. >> >> >> >>> any thoughts? >>> >>> 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/CAFXPr0u6rD3MErQGhRvhV5v9YbtrF4%2BUWa1PphECfXAtcniy-g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/beancount/CAFXPr0u6rD3MErQGhRvhV5v9YbtrF4%2BUWa1PphECfXAtcniy-g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAK21%2BhN94Jjp_-gjHXhOoSzGMdkeR_U8LAZFG9GpKayii-hpcw%40mail.gmail.com >> <https://groups.google.com/d/msgid/beancount/CAK21%2BhN94Jjp_-gjHXhOoSzGMdkeR_U8LAZFG9GpKayii-hpcw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAFXPr0vMbo6omq3EZu9_-v%2BN3iZ%3DAfcPvPzc9q65tyNe%2BzSaQw%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAFXPr0vMbo6omq3EZu9_-v%2BN3iZ%3DAfcPvPzc9q65tyNe%2BzSaQw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAK21%2BhOJzH1kBXy%3DL6%2BVYbmg9NSyGFpimxJ7DQ7OJrEBiR_NTA%40mail.gmail.com.
