Stock trades and realized gains/losses

Linas Vepstas linas@linas.org
Fri, 10 Jan 2003 12:39:51 -0600


Hi,

caution: very long note. that, and I was rather irritated as I wrote it.


> > > Assets
> > >     Cash
> > >     COI
> > > 
> > > Income
> > >     RG(L)
> > > 
> > > Account         Debit   Credit      Bal
> > > ------------------------------------------
> > > Cash                    100         100
> > > COI             100                 100    <--- 10 shares @ $10
> > > ------------------------------------------
> > > RG(L)                   100         100
> > > Cash            200                 100    <--- 10 shares @ $20
> > > COI                     100         0
> > >  
> > > In the above, the number of shares and the price/share is ancillary
> > > information, and properly belongs in the Lot attributes.  Therefore, in
> > > our "Stock" accounts, we should be tracking the currency amount instead
> > > of the number of shares.  

The above example misrepresents how gnucash currently works.

A transaction indicates a 'balancing currency', which is used to value
all of the splits to determine if the transaction balances.  It is
non-sensical to talk about 'balance' without indicating what the
balancing currency is. 

Stock accounts *must* count the number of shares in the account.  When
a trade is performed, you are selling one type of object (a stock) for
another type of object (dollar bills).  What you must count is the
number of objects.   Value is gained/lost in the fluctuation of the 
exchange rates.  Value is determined by expressing all quantities of 
all objects in one common currency.

> > The problem with this model is that while you can easily track the
> > gains/losses, you cannot track the "current value" of your holdings.

Huh?  the current value of your holdings equals the number of shares
times the current price.

value = quantity * price.

The quantity of shares that you own is the balance of the account!  
That's what the words 'current balance' mean!

> > At no time can you easily determine "I own N shares of XXXX", because
> > that information is stored throughout the dataset.  

Maybe I'm quoting out of context, but this statement, taken out of
context, is insane.   I can determine that I own N shares of XXX 
because that is what the current balance of my account is.

Determining the balance isn't always easy, especially after a
large number of transactions.  But this is exactly *why* one does
accounting, and uses accounting programs: to determine the current
balance of an account.  There is no other way; one fundementally 
cannot make a categorical assertion as to the balance.  (Other than
'possession is 9/10ths of the law' ;-)


> I do seem to recall seeing, however, a complaint in a comment somewhere
> about not being able to use C++, but the author was still intent on
> proper opacity of object. =P   There really isn't a reason we couldn't
> subclass the Split entity into a StockSplit entity, or similar.  That

?? This is off topic.  Gnucash doesn't condon C++ style subclassing 
because C++ subclassing is a massive headache for the writers of 
the storage backends, never mind for the writers of the scheme reports.
We provided the key-value pair mechanism precisiely to avoid the 
problems of C++ subclassing.

> Another possibility is to calculate checkpoints much as the the PG
> back-end does. 

The balance checkpoints are an SQL performance hack. 

The 'normal' way to compute the current account, based on generall
accepted accounting principles is to take the opening balance, and
to add/subtract the value of all transactions since then that affected
the account.  This gives you the current balance.

Then, once a month, or once a quarter, one audits one's accounts,
checks to make sure that the balance is correct, and then once 'closes
the books'.  The act of closing causes the balance to be recorded in 
a permanent way:  it then becomes the 'opening balance' for the next
book.  Closed books mustn't be modified because that would screw up
the opening/closing balances.

By closing one's books every now and then, one can make sure that 
one doesn't have to zum a gazzilions transactions to determine the
account balance.

The PG backend 'checkpoint' is just a cheesy way of determining
intermediate balances for performance reasons.  The correct solution
is to implement books, and allow them to be closed & etc. according
to normal accounting principles.

> Or extend the Lot instead of the Split (probably an
> easier direction, but I haven't looked at it too hard).  Create a
> StockLot, and InventoryLot, etc.  The Lot has some basic functionality:
> extend it.  That's one of the key principles in OO A & D.

No.  This is one of the key reasons why languages like C++ are broken.

This is off-topic, but important to understand.  Things like the OFX DTD
define a set of 'classes'.  If you mirror these classes in C++, then you
have quick-set concrete: if OFX ever changes, then you have to recompile
and reinstall a million clients, all on the same day.  This makes for
a very very fragile infrastructure.  This is why people who do
distributed client-server programs have invented things like 'Any'
and 'DynAny' and object factories and ASN.1 and XML and the like:
you avoid defining your classes at compile time; instead you define your
classes at run-time, as best as you reasonably can.

(This is one reason why the first gnucash ofx implementation was a bad
idea: it created hundreds of compile-time C++ classes.  It took a while
before I really came to terms with why this was unmangegable.)

> you do.  The values used in net worth should be based on the recorded
> purchase cost, plus or minus any adjusting transactions for unrealized
> gains (loss).  

I don't get this.  How do you plan to record a transaction for
unrealized gain?  

> > Similarly, what you are asking for necessarily requires you to define
> > a common currency for ALL your accounts.  

If you want to express your net worth in dollars, you must have a way
of valueing *all* of your possession in dollars.  This means both
having a price on hand for every object, *and* declaring a 'common 
currency' for that *report*.    Different reports may declare different
common courrencies.  This is a report issue, not an accounting issue.

> You could have an account per exchange, I guess, and record figures in
> the currency of the exchange.  Multi-currency will always be an issue
> regardless of the discussion at hand.  

Huh? From the accounting persopective, there is *no* difference between
widgets, stocks and currencies.  You merely count how many widgets,
stocks, currencies you own.   And this is how gnucash works.  We simply
use the word 'currency' as a convenience term: a currency is a widget
that other people are willing tto accept as a payment of a debt.  By
convention, it is paper money issued by governments.

> I had thought that there was some
> effort being put toward a way to transfer money between accounts of
> different currencies.  

The problem in gnucash with currencies was not in the accounting
thereof, but in how the general ledger window displayed things.  
The multi-currency GUI needs work.  In much the same way as the 
multi-stock general ledger needs work.

> always have to deal with cross-currency transactions.

In the gnucash accounting subsystem (the engine), cross-currency 
transactions are dealt with in *exactly* the same way as the sale of 
stock or widgets or any other items.  Its just an exchange of N objects 
of type A for M objects of type B.  This is the way it should be, and
it shouldn't be changed.

> > It means you have a "can't get there from here" issue, which means the
> > register would have to be currency-aware and only allow you to make
> > transfers across a common currency.  

Well, yess, in way, the register needs to be currency aware.  The
currenct registers still display things wrong or non-intutitely
in many cases.  Its one of those things that have been irritating
me for a long long time.

> > A Currency account would be
> > "special", 

No.

> > in that the transaction can be denominated in "either"
> > currency. 

Transactions have only one 'currency', and one or more commodities.

For example, I can trade N objects of type A for M objects of type B,
and value the transacation in currency C.

Niether type A nor type B need to be type C, although they may be. 

The types of A and B are recorded in the repsective accounts.
The account can only hold objects of types A,B, ...

The currency C is recorded in the transaction.  There do not have
to be any accounts that actually count type C.    Type C is only used
to declare the balancing currency for the transaction.  For simple
transactions, C is not needed and is irrelevant, but there are 
more complex transactions whose *valuation* would be ambiguous, which 
is why the currency type C must be recorded with the transaction.

WhenI say *valuation*, I mean 'quantity' * 'price'.

You can express the value in units of A, B or C.  Certain rare,
complex transactions require that the value be computed in C first,
and then converted (by prices) to A and B.

> >  A stock account would still only be allowed to have
> > transactions denoted in its currency.

Stock accounts do not have currencies.  This is an old and broken 
pradigm left over from gnucash-1.2/1.4 which is supposed to be 
eradicated real soon now.


> > Well, Linas had lot's "done" for a while.  I fixed a couple of bugs in
> > them, but they are there and have been for a while.  They just aren't
> > being used by anything except A/R and A/P invoice/payment tracking.

The next missing piece was to create the FIFO's, LIFO's and/or
other accouting depreciation scehdule, etc.  machines so that realized
gains/losses & depreciation could be computed.  (and so that books could
be closed).

The third missing piece is the GUI to deal with this.  I have a pretty
clear idea of what the FIFO's need to be like; and I think I can 
impement thim in under 40 hours of work.  I have not really thought
about what one needs/would like to have for a GUI.  There's a *lot*
of gui work, potentially, for dealing with opening/closing of books,
selecting dprecation schedules, selectiong FIFO or LIFO accounting,
etc. etc. etc.  The GUI is the hard part.

> > stock portfolio is NOT inventory.  With inventory you want to know how
> > much you paid for your assets, and subtract out depreciation.  But

Lots are designed to handle depreciation.  That is one of the reasons
they are there!!
  
> > The reason is that there is not a 1:1 mapping of
> > purchases and sales.  

The whole point of lots, and of FIFO's, is to deal with the fact that
there is *not* a 1-1 mapping of sales and purchases.  This is *exactly*
the problem that lots are designed to solve.

> Each transaction should be balanced monetarily.  This is possible if you
> track the balance in currency instead of shares, and track the purchase
> cost vs. today's volatile market price. 

Which balance? the account balance or the transaction balance?  the
account balance is always expressed in shares.  The transaction balance
is always valued 'monetarily', in the transaction currency.

The GUI register should show balances in *both* shares, and in some
arbitrary currency R, the 'reporting currency'.  Currency R has nothing 
to do with the currency C that a transaction is balanced in (although
both will probably be dollars for americans.)  (By contrast, C may be
dollars for mexicans trading on the NYSE, but R will be pesos.)

Lots and fifo's deal with the purchase-cost vs. today's price conundrum.

>  Record the number of shares and
> price as we do now, and offer a warning if price * share !=
> debit/credit.  

??? why is this a warning??  This is eactly the definition of unrealized
gain/loss !

> > Now, let me show you how this looks from the LOT view.  In paricular
> > the Lot view has the following splits:
> > 
> > (type)	amt	val	(amt-bal)       (val-bal)
> > buy     10      $100	10              $100
> > sell    -5      -$150   5               -$50
> > (gain)  0       $100    5		$50
> > 
> > The (new) invariant of a Lot is that it is "closed" when both the
> > sum-of-amount _AND_ sum-of-value is zero.  That way you know it is
> > closed when you've accounted for all the shares _AND_ all the
> > gain/loss.

Yes, exactly.  Except you didn't show the lots in the above example.

The original buy of ten shares went into two lots: 5 shares into lot #1
and 5 shares into lot #2.

There are were 5 shares removed from Lot #1 in the sale, and 
a realized gain made, and so Lot #1 is now closed.

There are still 5 more shares in Lot #2, which is still open.
Lot #2 has an unrealized gain, depending on todays prices.


> > If we do it this way, then:
> > 
> > a) you get your gain/loss split
> > b) I get my "net value" and holdings balance
> > c) it does not require a major architectural shift in the way gnucash works.

yes, exactly.

> > This would require two minor change to lots.  First, you need to
> > enforce that all transactions within the lot are denoted in the same
> > currency.  

Umm, uhh, gurgle, yes, lots need to double-balance.  But I this reminds
me of an earlier problem that we had ... 

> This will always be a problem, at least until *everybody* is using the
> same currency *everywhere*.

No, one merely need to have registers, ledgers and reports know what
thier 'reporting currency R' is.  


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