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

Linas Vepstas linas@linas.org
Fri, 10 Jan 2003 23:19:46 -0600


OK,
There are gui issues, and there are engine issues.

Below follows an algorithmic rewording of Derek's 
stock-valuation proposal; algorithmic, so that its 
closer to the calcs the engine would have to do.  
I think it solves most of Mathew's complaints on the 
engine side.  Unfortunately, it has some bugs.

----------------------------------------------------------

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.

If some splits are in one commodity, and others in another, then
we can't force a zero balance as above.  Instead, we will force
a different requirement, the 'double-balance' requirement:

-- All splits that are *not* in the transaction currency C
   must be made a part of a lot.   (Thus, for example, 
	the transaction currency C is dollars, whereas the split
	commodity is 'S', shares of RHAT.  If a transaction
	has C in dollars, and 'S' in RHAT, then the S split must 
	be made a part of a Lot.)
	
-- The lot will have a designated 'lot currency' L that must
   be the same as the C of every split in the lot.  One
	cannot enter a split into the lot if C != L.  (That is,
	if I'm working with a Lot of RHAT shares, then *all*
	splits in the lot must belong to dollar-denominated
	transactions.)

-- When a lot is closed, we must have the 'double-balance'
   condition:  The sum total of all 'S' is zero, and the
	sum total of all 'C' is zero.  Thus, if I buy 100 shares
	of RHAT for $5 and sell 100 shares of RHAT for $10, then
	I *must* also add an 'adjusting transaction' for zero
	shares of RHAT, at $500.  If there is no adjusting transaction,
	then the lot cannot be closed.  If sum 'S' is zero,
	while sum 'C' is not zero, then the lot is declared to 
	be 'out-of-balance', and an 'adjusting transaction' must 
	be forced.

It is only by 'closing a lot' that I am able to regain 
'perfect balance' in the books.   That is, the 'double-balance'
requirement is the generalization of the 'double-entry'
requirement for stock accounts.

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.

I think this satisfies Matthews requirement: the ablity 
to add any number of 'adjusting transactions' that will
credit an 'unrealized gain/loss' account while the lot
is open, and force the monetary value of the lot to
balance when the shares are finally sold.

I think it can also be implemented with little or no change 
the ledger GUI, which is good. But ...

--------------------------------------------------------
The above seems to work for simple stock-transactions, but
fails in other more complex cases.   Here's an example.

Imagine 'S' is in euros, instead of 'RHAT'.  So I sell
100 dollars, and buy 110 euros.  This causes a lot to open
up for the euros, with the lot currency 'L' in dollars.
Now I try to transfer the euros to other euro accounts.
What happens to the lot?  Do I have to give up on it? 
How can I save this bad situation?

A similar problem occurs for more complex stock transactions:
If I buy 100 shares of RHAT with Schwab, and transfer them
to another account with Etrade, then I have the same lot
closing problem.   There's an even worse scenario, where
I move to brazil, and take my RHAT stock (purchased in dollars)
to my brazilian broker (who will sell them for cruzeiros).

Is the correct answer to just 'punt' in these cases? 

There are other, crazier scenarios:  transactions containing
three or more currencies in them.  (Example: AT&T spins
off a subsidiary X, giving stock in X and a cash payout.).
Ugly; maybe we can prohibit this and force two transactions
to be used ?

Then there's the dreaded, the horrible dual-currency
'split-restaurant-tab' (which can easily occur if you
dine with freinds in a foreign country and put the tab
on your domestic credit card.).   If treated as multiple 
transactions, its not really a problem, but if treated 
as one transaction, there are some simple scenarios that 
can cause incorrect exchange rates to be deduced.

--------------------------------------------------------

Finally, there are the GUI issues.  I think the proposal
at top can be accomodated by the current GUI with minimal
or no changes.  But what Matthew wants (and what I want)
is to be able to see stock ledger values in dollars,
and to have ROI and cap gains and rate of return displayed
in reports.  The lot mechanism will help compute cap gains,
but someone still needs to design the visual layout, etc.

OK, I'm rambling. Now what?

--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