On Tue, Nov 17, 2020 at 12:21 AM Ben Blount <[email protected]> wrote: > 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. >
SGTM. I think a good way is to write out small scenarios in unit tests illustrating those cases I enumerated and you'll think of more. The loader.load_doc() helper and the corresponding parse_string() for expected outputs make it really easy to do that without having to write any real code. 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? > I... can't remember. It's been too long. I ported the "booking_fixes" branch, maybe that's the one. Looking fwd, > 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 > <https://groups.google.com/d/msgid/beancount/CACGEkZtDSSdAFQKJ-afk_gKmwi%3DSDP2tfHw5zVycsY1G5RKx0g%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%2BhPgP%3D6RvK_OWKYm%2BTAaJC%3DpG34D2W%2BrdoXBoRhFfBrxzQ%40mail.gmail.com.
