Thanks for your interest Christopher. The circular nature of the problem is that interpolation may depend on booking, and booking may depend on interpolation. There's no perfect solution to that, that I could find.
The implementation of the Inventory has already evolved since this was written (for performance reasons) and IIRC is treated mostly like a list, matching portions that have been specified to filter a list candidate positions. I'm not beyond reviewing core classes - especially if it might help - but I believe changing the mapping would make no difference at all here. I wrote an example some time ago - in a text file IIRC, which I shared on the list and had some comments about - but I can't seem to find it right now. On Wed, Jun 12, 2019 at 12:27 AM Christopher Singley <[email protected]> wrote: > I've been reading through this: > > http://furius.ca/beancount/doc/self-reductions > > and puzzling through parser.booking_full. > > It looks to me like the root cause of your struggles is that the keys to > your > Inventory mapping are overspecified - the necessity to perform the > calculations to > populate a Cost instance in order to look up a lot. I reckon you need > to move > the cost data from keys to values, so that inventory is a mapping from > (account, security) -> [(units, cost, date)] > instead of the current mapping from > (account, security, cost, date) -> [(units, )]. > The former is a more natural data structure for cost accounting. > > Any well-formed transaction natively has (account, security) fields. > Use those to look up a sequence of lots containing (lot_units, cost, > open_date). > Filter that sequence using (transaction_date, transaction_units) to find > lots that > might be closed ("booked") by the incoming transaction - it will > definitely have > transaction_date, and if it doesn't have transaction_units for some > reason, then that > is trivially interpolated. > > Next step depends on your cost accounting method. Normally you'd sort > transactions > by date/time to do FIFO or average cost. To instead do specific > identification, you'd > further filter the lots for a particular date/cost/label, and require a > unique result. > > NOW you do the heavy lifting. > > Work through the surviving lots in order, popping lots and splitting > them as necessary > until you run out of transaction_units or lot_units. For each popped > lot, couple its > data to (transaction_date, transaction_units, transaction_price), > and you'll have all the data needed to fully populate a journal entry. > > There's nothing recursive about this calculation. You can implement it > as a straight > pipeline of iterators, evaluated lazily. > > An additional advantage is that this procedure is easy to extend to > handling other > securities transaction types that don't involve realizing gain. > E.g. for a split, use (account, security) to look up your position. > Filter that sequence for lots with an open_date before the > transaction_date, > and replace them with copies with the units/cost adjusted for the split. > Keep a running total of the change in units, and require that total to > match the input > transaction_units (which is a hard requirement for a stock split > transaction). > > Any conceptual problems with this setup? I mean, other than being a > huge PITA to > rip up existing classes and everything that touches them. > > -- > 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 post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/e84f305c-9282-1d20-d74d-00d99620f2da%40singleys.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhMdR0vjQ90owEBLSU16yOeURNqOhtkc92oPzk%2B8MB-L_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
