[EMAIL PROTECTED] writes:
> prices are recorded in a transaction with a single, dangling entry.
> This is allowed since prices 'have no value'.
OK, so that would solve the "stock split having no transfer-from"
problem, as long as the engine knew to ignore them when force double
entry was on...
> > 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.
>
> I don't like this because its 'added complexity'. I think that if
> we can make the register display properly when we debit & credit the
> same account in the same transaction, then we'll also have the split
> problem solved.
I see two potential problems with this. First we'll need to make sure
that the engine can tell that it's a stock split and not a
sell/repurchase. Otherwise we'll never be able to have reports that
allow the user play with their tax calculations.
Second, this seems a little messy. What if you have bought and sold a
stock 10 times over the past 5 years, and most of the sells were only
fractional (say you needed some cash for something), and were never a
significant amount of any one purchase, and now the stock splits.
Don't you now have to figure out what your total current number of
shares by hand across all of those transactions to be able to enter
the split transaction? That seems much harder on the user than just
entering
("2000-01-01" split mega-corp 2.0)
and letting the engine figure it out. Further, if you made some
mistake in entering data before the split, whenever you make any
changes, you'll be required to manually update *all* of the subsequent
"stock split adjustment" transactions...
Given this, unless we think of a better way, I'm still leaning in
favor of running share totals...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
