Christopher Browne <[EMAIL PROTECTED]> writes:
> You're surely right about the split not indicating a fresh event from a
> cost point of view.
Right. ATM the problem is that right now I think the engine wants
every split (engine split, not stock split) to be a double-entry event
-- I'll have to check the engine. So I don't think it would be too
happy with what you're proposing, but I think we may need to consider
changing that.
> So, if RHAT splits 2 ways on April 1, 1999, and then again splits 3 ways
> on July 1, 2000, there would be two entries:
> ("RHAT" "1999-04-01" 2)
> ("RHAT" "2000-07-01" 3)
This looks pretty good. I was trying to see if I could think of any
problems that this might introduce when the splits are interleaved
with sales of various sizes, but so far it seems OK to me.
There's still the problem of calculating the cost basis, or
determining *which* shares you sold when you sell a stock that you own
at multiple prices, but that's a reporting issue, and one you have to
decide when you file your taxes, not a data storage issue.
> Sadly, this Makes Life More Complicated, adding a further data structure,
> and a mandatory calculation which imposes itself into stock activities.
Well we might be able to just store the split events in the data
stream, and generate the number of shares as a running total just like
we do for balances. That might make more sense, and having a column
showing how many shares you own at any given time might be useful, but
this is just off the top of my head. I'll have to think about it...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
