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.
