It's been rumoured that Rob Browning said:
>
> [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...
(from now on lets call xaccSplit a 'je' (journal entry).)
Prices are recordable in a single 'je' because
(zero shares) * (any price) == (zero dollars)
so additional 'je's are not needed to balance. Prices are 'trivial'.
> > 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.
There should be no confusion. A sell/repurchase occurs when some
money is transfered to a bank account (and that is a taxable event).
A stock split doesn't transfer any cash anywhere. It is mearly a
transaction with two je's in it, where both je's are in the *same*
account. It still has to balance, just like any other transaction:
(100 shares) * ($100) - (200 shares) * ($50) == (zero dollars)
there was no money actually moved to a bank acct. thus, no taxes.
And since it still balances, the books don't get messed up.
> 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.
As indicated earlier, the recording of a transaction is independent of
how one figures out running totals, or how one figues out cost-basis.
> 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?
Yes, and that total number of shares is shown in the second-from-right
hand column. A user can either manually copy that number when manually
creating the stock-split, or we can have a little dialogue window that
automates this.
> That seems much harder on the user than just
> entering
>
> ("2000-01-01" split mega-corp 2.0)
I understand that this proposal requires having the engine store
je's which contain not two, but three numeric values: amount, price,
multiplier. If you look at the difficulties that multiple currencies
already offer, adding yet a third thing into the mix could be deadly.
Recall,
Amount == amount of item x
price == cost of x in units of y
and we already have some icky sematics for matching x's and y's
throughout the engine & trying to make them balance. Putting a
multiplier in is just asking for more confusion, especially when it
seems that the existing engine infrastructure works just fine.
(Its only the register display that isn't/can't display correctly).
> 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...
Ahh, now *that* is interesting. However, this problem is not solved
with a multiplier. Its rather solved with a different thing: instead
of hard-coding an amount into a 'je', you are arguing that instead, the
amount should be a pointer to some computed quantity. Suddenly, the
'amount' field in a 'je' looks more like a spread-sheet cell, with some
arbitrarily complex formula in it .... well, you can follow that train
of thought for a while ... imagine updates, recalculations, directed
graphs without circular loops in them, etc. Its interesting, but its
a different order of magnitude.
--linas
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
