Stock trades and realized gains/losses

[Linas Vepstas]

On Fri, Jan 10, 2003 at 11:43:44AM -0600, Matthew Vanecek was heard to remark:
> > 
> > False.  

> No, it's true.  

> To be clear, I'm not saying track one or the other--both share quantity
> *and* purchase need to be tracked, but the balance of a stock account
> needs to be calculated in terms of dollars, not quantities.  That's just
> (not-so-basic) accounting. ;)

Uh, there's a semantic problem.  We need to distinguish the 'balance'
viz. how much of thing A that I own, from 'value', the value of the
balance of A expressed in reporting currency R.    It is vital that
the stock register show the value of my balance of stock in dollars
(i.e. R is dollars).   It is very very interesting to see what
the value of a stock account is, in dollars.  But the balance is still
in units of A, converted to dollars by multiplying by price.  This
is very, very different than maintaining the balance in dollars
(which would be accunting-wise incorrect).


> Yes you're right, yes, you're right, no, you misunderstand.  Net worth
> is *not* quantity * price.  Net worth uses current balance, in general
> accounting.  If you *want* quantity * price, I'm certainly not opposed,
> and would probably use it.  However, both methods should be supported,
> with the account balance measured in dollars (sum of purchases +/- sum
> of adjusting transactions).  As it stands now, there is no way to
> logically put in an adjustment transaction, which comes from the
> insistence of price * quantity, rather than actual cash expenditure.  I
> can't record an other than temporary change in the value without
> recording a buy/sell, which is just...

OK.   I don't understand.  How do you propose to record a temporary change
in value? 

Part of the idea behind lots was to be able to rationalize how both 
realized and unrealized gains are handled.  If you wanted to record
an 'unrealized gain', you would withdraw all N shares in the acount,
and then put all N of them back into the account, in a new lot.  
The balancing split in the closed lot would be the unrealized gain/
loss, and that split would go into an account fo type 'expense/income'.

> > A realized gain/loss occurs only when a stock is bought/sold.  There's
> > supposed to be a split that goes into an income/expense account to 
> > record this gain/loss.  (The absence of this split is one of the things
> > that's broken about the current gnucash).
> 
> Which is why this *whhoooolleeee* thing started! ;)

yeah, well, its been irritating me for years, and every time the topic
comes up, I get irritated.  Especially since gnucash-1.2 was a lot
(pun haha) closer to doing it right it is now.

> My issue is not that we track share quantity, but rather that we insist
> the value of a holding is the immediate price * quantity.  As you
> mentioned (and I'm sure we all agree), we definitely need a split to
> record a gain or loss.  If we can get that, we're much closer than we
> are now.  I would *like* to get to a point where I can track my holdings
> as I described--which allows for value adjustments, etc, and is much
> closer to gaap than just having a gain/loss split.  For example, if you
> cannot make value adjustments, then how can you possibly record an
> UN-realized gain/loss?  I could be missing something there, though..

note    shrs   price  value      lot-id
---------------------------------------
open     100     $10    $1,000     #1
value   -100     $1     -$100      #1
unreal    --      --    -$900      #1

open     100     $1      $100      #2


One handles an unrealized gain/loss by selling and then buying back
immeidately the smae amount.

I want the engine data to be recorded cleanly.  However, this has
the potential of making the GUI quite muddy, since what the GUI shows 
does not ahve a 1-1 correspondance with what is stored in the engine.
In the above example, the GUI should hide the fact that multiple
transactions were used to record the unrealized gain/loss.

yess, this potentially makes the gui even messier than it already
is, and I don't currenlty see a good way out of it.


> To sum up:
> 	1) The current storage format seems OK, esp. since balances are
> 	   calculated dynamagically.  At most, I think an additional
> 	   field in Split would be useful--shareBalance or
> 	   purchaseBalance, depending on how this discussion goes.

I want to have a 'reporting currency' used in ledgers and reports.
Each leger/report could have a different reporting currency.

> 	2) We definitely need a split for realized gains/losses.

yes, and 'double-balancing' the lots would provide this, and
enforce the balance.

> 	3) I would like to see a stock account balance measured in
> 	   dollars, not quantities. This does not mean quantities
> 	   should be hidden.  Perhaps an option to control this
> 	   would be acceptable. [if (x) calculateShareQtyBalance;
> 	                         else calculatePurchaseAmtBalance;

Measured in, or displayed in?  I think there's a real difference
here, and it affects things.

Note in earlier email, I distingusihed the transaction-balancing
currency C from the reporting currency R.   I think that you are
requesting that the ledger display a balance using C, not R, 
which is fine by me,  although there are again some subtle 
differences betweeen the two that will keep gnucash-user mailing
list lively for years to come.

> Hopefully this clarifies my position a little.  I really don't
> understand how accountants deal with this crap all day every day!! ;)

ha !

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