Implementing proper cost basis tracking for shares

[Rob Browning]

Robert Graham Merkel <rgmerk@mira.net> writes:

> As far as I can see, all we need is for each share account to store
> a table with the details of the currently owned parcels, and each
> "sell" transaction to contain the details of which parcels have been
> sold.

I'm not fully versed in all the financial ramifications, but I left
that discussion thinking that practically speaking, we could really
only track the events (buys/sells/splits/etc.) as the "facts", and
needed to leave the computation of cost-basis, etc. up to a separate,
and more flexible, "computation" process that would run later.

Another thing I recall is that whatever we do, we need to be very
careful to make sure we can unambiguously reconstruct what happened -
we have to be able to tell which transaction splits are purchases,
which are commisions, which are stock splits, etc.  I'm not sure we
ever determined whether or not we could always do that implicitly, or
whether or not we were going to need to start using special "tags" for
each type of thing...

Finally, if I'm understanding your question about using multiple
accounts correctly, then I think that's *exactly* what the QIF
importer does, and is probably the right thing, at least given our
current setup.  i.e. if you have a stock/mutual-fund, you'll probably
also need a parallel income account for dividends, etc.  We might even
want to make creating any parallel accounts part of the "Buy stock"
helper process, as an option that's enabled by default.

Having several accounts of various types associated with every
security is currently a little awkward for people who'd rather see all
their stock-related stuff together, given our soemwhat primitive
"chart of accounts", but we can change that later.

Dave, do you recall what conclusion we came to, if any when we were
musing about the possibility of (internally) killing off the account
heirarchy altogether?  ISTR we talked about the possibility of just
having one large flat account list, and then representing heirarchical
organizations of these accounts as trees containing pointers into the
global list.  In this setup we could relax the type relationships --
and even show multiple different organizations of the accounts.

You might want one view that organizes by type, with all the income
accounts together, all the expense accounts together, etc.  You might
want another that organizes by institution, with all your Fidelity
accounts/stocks/etc together, all your MegaBank accounts together, and
all your credit union accounts together....

I don't really know how much flexibility we'd want to allow initially,
but changing the internals at some point might make accomodating
various different schemes easier.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930