Next [was Re: Stock trades and realized gains/losses]

[Linas Vepstas]

On Sat, Jan 11, 2003 at 12:01:57PM -0500, Derek Atkins was heard to remark:
> Linas,
> 
> Thank you for this great summary.  Mind if I ask a few clarifying
> questions?
> 
> linas@linas.org (Linas Vepstas) writes:
> 
> > Transaction balancing: If all splits in a transaction are
> > in the same 'currency' as the transaction currency, then the
> > sum of the splits *must* equal zero.  This is the old, existing
> > double-entry requirement as implemented in Gnucash, and doesn't 
> > change.
> 
> Are you referring to split->amount or split->value?  I thought that
> regardless of what commodity the split->account points to, the
> split->value of all splits in a transaction must equal zero.  This
> should be true regardless of whether it's a one-commodity,
> two-commodity, or N-commodity transaction.
[...]
> Well, we certainly cannot force a zero-balance on the split->amount,
> but we can still force a zero-balance on the split->value.

Yes, right.  Mentally, I discount this, since, for multi-commodity 
transactions, one can set the value to 'anything', as it were.   
Its a kind-of meaningless balance, because changing the 'value' just
changes the 'price', which isn't double-checked against anything,
and could have any value.

The point being that if one adds an extra zero to the value/amount, 
one might go for a while before finding the mistake, since the act 
of balancing doesn't catch it (it just assumes the 'price' changed).  

This can't happen when all splits have the same txn currency, 
a mistake really does alter overall balance.

> I do like this idea a LOT (no pun intended).  It would just require a
> small change to gnc_los_is_closed(), but would require a bit for work
> to determine if a lot in "out of balance"...

A bit of work?  Like what?

> > Note that because the 'adjusting transaction' has one split
> > in dollars, and another split in RHAT shares (albeit for zero 
> > RHAT shares), it evades the old double-entry requriement,
> > and will not be flagged as 'out of balance'.  Note also 
> > that because the 'adjusting transaction' contains a split
> > holding S (albeit zero S), it *must* be a part of a Lot.
> 
> But it IS in balance by the old rules.  The split->value is in
> balance.

Well, its a 'weird balance'; its a good example of what I mean 
by 'multi-commodity transactions fundamentally can't balance'.

The split in the 'unrealized' account shows amt=$1000, value=$1000
The split in the 'stock' account shows amt=0 shrs value=$1000

If you look at the above 'adjusting transaction' on its own,
you conclude an infinite price. Yuck.  To compute the prices
corrctly, you have to find the lot that this belongs to, and 
assume that the lot shares were all sold and then rebought 
at $1000 less.  This means that any kind of split_get_price()
routine needs to also be made more complex.  Ugh. There are really
*two* prices involved ...

I think we've already rejected the alternative way of recording this:

The split in the 'unrealized' account shows amt=$1000, value=$1000
One     split in the 'stock' account shows amt=-100 shrs value=-$8888
Another split in the 'stock' account shows amt=+100 shrs value=+$7888

primarily because the register would display a rather confusing pair
of buy/sell splits.   Or would it?  I'm not convinced the latter
will have an uglier display than the former.

> Let me leave the more complicated stuff for another email..  Let's see
> if we can come to closure on the simple stuff first?

I'm ready ...

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933