There's a vaguely related question around my attempt to find a good way to work automatic cost basis transfers into Beancount transfer transactions.
When you move assets from account A to B, if you want to automatically move cost basis along with, you need to automatically select which lots are moving. This is basically the same as booking a sale, but there's no particular reason to assume that one wants to use the same method for lot selection as one uses for sales. (In particular, the most common case for this functionality seems to be crypto users, in which case the transfer may be to cold storage, in which case one probably wants exactly the inverse lot selection one uses for booking sales.) So at this point, what I'm looking at is making booking decisions based not just on the cost basis and cost date, but the date (to use different algos over time), as well as the accounts of the augmenting and reducing legs. Agreed on the "unclear if it's worth it" for Beancount, although I kinda need it (and already hacked it up) for myself. On Thu, Aug 22, 2024 at 7:39 AM Eric Altendorf <[email protected]> wrote: > Ok, I was just thinking there might be a spot where I could (in my own > patch) inject a serialization call. It wouldn’t be generally useful (since > it wouldn’t retain comments or order etc) but it might be good enough for > my immediate needs. > > Thanks for the responses! > > On Wed, Aug 21, 2024 at 23:40 Martin Blais <[email protected]> wrote: > >> >> >> 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 >> <https://groups.google.com/d/msgid/beancount/CAK21%2BhOJzH1kBXy%3DL6%2BVYbmg9NSyGFpimxJ7DQ7OJrEBiR_NTA%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/CAFXPr0utUC7%2B9vmPDANqd0C-S5%2B51grkaEkwgKWfe6ZjNtniZA%40mail.gmail.com.
