[EMAIL PROTECTED] writes:
> 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.
The reason I hadn't suggested this approach was that I thought we had
a previous conversation some long while back where I got the
impression that the engine would throw a fit if you had a transaction
that referred to the same account in all it's je's. I think that was
the same time I was migrating from quicken/cbb, so it's possible that
I was just surprised by the result (net sum zero effect, which is not
what quicken did), and then filed that mentally as a bad idea across
the board, even thought it apparently isn't...
> As indicated earlier, the recording of a transaction is independent of
> how one figures out running totals, or how one figues out cost-basis.
Right. That I knew.
> 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.
Definitely plan to, though first I want to document this correctly.
> 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).
Perhaps, but the bit below makes me think we should at least consider
the possibilities carefully. For now, using the manual approach above
and marking all the je's involved with the split action should be
workable, and if we do something fancier later, we can always scan and
convert...
> > 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.
Actually, I'm saying that we need a special kind of je where the only
relevant value is a multiplier, so it only has an affect on the
running total but doesn't contain any other relevant values itself.
You could overload the price field to hold this value, though if you
had the flexibility, this would most naturally be thought of in terms
of a union in C parlance, or a subclass in object oriented parlance.
If it's a normal je it has a price, and if it's a stock split, it has
a multiplier...
Of course handling things this way might make other actions too
complicated, but this is how I was thinking about the problem. It
seems to record the minimum information associated with the split
event -- just what actually happened...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
