Implementing proper cost basis tracking for shares

[Robert Graham Merkel]

Rob Browning writes:
 > 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.
 > 
Correct.  We only need to record which shares are sold - the
computation of costs is done at the reporting stage.

 > 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...
 > 

I'm not sure on the stock splits issue.  Maybe I should re-read some
of the archives on that.

 > 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.
 > 
Yep.

 > 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.
 > 
Yeah.

 > 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.
 > 
I dunno if you saw the discussion I was having on the list a while ago
about being able to do this, but only for reports.  If we generalised that to
*everything*, it would be an interesting possibility :)

------------------------------------------------------------
Robert Merkel	                           rgmerk@mira.net

------------------------------------------------------------