Great, glad to hear Martin! I'll start with a doc similar to your docs that outlines the implementation decisions to be made, offering options for each. Once we have consensus on those and if it still looks doable for me, I'll start building out the testcases in a branch on my own repo. I saw some references to previous testcases written in a 'booking' branch. I don't see that branch anymore, perhaps it was on the old git provider. Do you know where these are / are they worth reusing?
On Mon, Nov 16, 2020 at 6:48 PM Martin Blais <[email protected]> wrote: > On Mon, Nov 16, 2020 at 9:02 PM Ben Blount <[email protected]> wrote: > >> First off, thank you so much for such a great tool! >> One challenge I haven't been able to solve yet with beancount is tracking >> basis for my US 401k - average cost booking. >> >> I did quite a bit of digging into the code, TODOs, and the mailing list. >> I actually implemented average cost booking on augmentation and reduction >> as a plugin, but it's not possible with just a plugin due to booking >> running before plugins do (makes sense- having resolved lots is very >> useful). >> >> My summary from investigations: >> >> - It's >> <https://groups.google.com/g/beancount/c/SP5KeksHbCk/m/aIMfFDMRBQAJ> >> been >> <https://groups.google.com/g/beancount/c/72PN-d-je40/m/lHQZf6O0CQAJ> >> asked >> <https://groups.google.com/g/beancount/c/dOrCPTbHZKY/m/vhPipQaVAQAJ> a >> fair bit on the mailing list. >> - The best workaround currently is to use the "NONE" booking method >> and manually summarize it everywhere you need to. Martin has a decent >> workaround here. >> <https://groups.google.com/g/beancount/c/TjOnum255Ps/m/hDFkdqCaAwAJ> I >> wrote a plugin to automate some parts of Martin's >> - Since it touches the heart of the balance update mechanism it could >> break many things if done without care. Martin previously (understandably) >> would rather not accept it as a contribution. >> <https://groups.google.com/g/beancount/c/SP5KeksHbCk/m/bOXNBFOjAwAJ> >> >> Martin: Do you still feel the same way? I am wondering if perhaps you'd >> want contributions of unit tests for it? I'd love to do anything I can to >> help get AVERAGE booking going, my 401k has a lot of history and >> contributions so it's a big chore to track. >> > > Yes, nothing much has changed. It's possible to do, I just think it > might create a lot of unexpected work, but it's possible. FWIW, I want that > feature too! If you're willing to (a) include tests covering most corner > cases for the code you're adding, (b) finish coverage of the feature to the > extent of not leaving too many loose ends and handle most of the corner > cases (will take more time than one might think IMHO, but what do I know > about your level of enthusiasm for this problem?) and (c) support it when > people report things that aren't working, at least until it's really > stable, I'm happy to review PRs. You can start the work in a branch too if > you prefer. > > There's already a method for it, and you don't even have to change the > syntax, start here: > > https://github.com/beancount/beancount/blob/master/beancount/parser/booking_method.py#L173 > > The way I think it would best be implemented is that on an augmentation or > reduction to an account marked as AVERAGE booking method, merge all the > lots from that account in each commodity to a per-commodity lot with the > average cost. Implementing that naively is not difficult. Optionally, you > could trigger the merging only on reduction (would work too, less rounding > errors, but less consistency). But... find a way to handle rounding errors > gracefully. Also, the resulting costs will be with long fractions (not > rounded)... or will they be rounded? If the costs aren't rounded, are users > going to be able to specify a cost value to reduce? How would that match > against the number they input if the costs have 20 fractional digits? > (maybe won't be that important since there's only a single position to > reduce from anyway and one could always elide the cost to match against it? > Is that true? I'd like to see it in tests, maybe that works well). How > about the case where there are multiple commodities in the same account? Or > the same commodity priced in different currencies, what should occur? > People will do these things. And how to deal with the case that would > result in a negative cost (e.g. inventory = 100 HOOL {60 USD}, + > reduction of -11 HOOL {600 USD}, what should happen? Raise an error? Or > allow negative cost? Okay, so say you decide to issue an error. What is > this occurs in a transient situation, e.g., that state only occurs as a > temporary state of an inventory while processing a jumble of reductions and > augmentations from the same transaction, the end state of which would be > legitimate?). My intuition based on the past booking features I've > implemented is that a lot of stuff like that will come up as you implement > it, and more that we aren't thinking about yet, but it's definitely worth a > shot. You can add tests for all these corner cases. If the issues I raised > in this paragraph sound new, I think the right way to go about this is to > try it out isolating each of these corner cases with dedicated unit tests > for each, and carefully document each of the cases in a shared doc with > examples as they come up, and solicit feedback and/or find creative > solutions to them, and document them, as liberal comments in the code or in > that doc. > > As for v3, if it works well, I would just convert that to the equivalent > C++ code, like the rest of the core (slowly underway). > > > > Thanks! >> >> -- >> 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/CACGEkZvQ_bFqf%3DKsriEC5qMJOj5r0Oh8c-bF6Cj-hT%3D2eAS7Gg%40mail.gmail.com >> <https://groups.google.com/d/msgid/beancount/CACGEkZvQ_bFqf%3DKsriEC5qMJOj5r0Oh8c-bF6Cj-hT%3D2eAS7Gg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Beancount" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beancount/1RRUo04hNbI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/CAK21%2BhNStTJ7QkSvKWJpYWDTwcUc%3DggROujgPB72_Ge0HaFW6A%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAK21%2BhNStTJ7QkSvKWJpYWDTwcUc%3DggROujgPB72_Ge0HaFW6A%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/CACGEkZtDSSdAFQKJ-afk_gKmwi%3DSDP2tfHw5zVycsY1G5RKx0g%40mail.gmail.com.
