Unrealized/Realized Gains and Losses

Linas Vepstas linas@linas.org
Fri, 3 Aug 2001 11:21:22 -0500


On Fri, Aug 03, 2001 at 08:36:22AM -0400, Derek Atkins was heard to remark:
> grib@billgribble.com (Bill Gribble) writes:
> 
> > On Thu, Aug 02, 2001 at 07:36:01PM -0500, Linas Vepstas wrote:
> > > To provide a specific example to chew on:
> > > 
> > > jan 15 1996 buy 50 units @ $10
> > > jul 15 1996 buy 50 units @ $15
> > > jan 15 1997 buy 50 units @ $20
> > > jul 15 1997 sell 60 units @ $18
> > > jan 15 1998 sell 60 units @ $19
> > > jul 15 1998 record new price of $23
> > > 
> > > what is the cost basis?  what is the realized gain? what is the
> > > unrealized gain? what's the 'long tem cap gain'? what's the 
> > > 'short term cap gain'?  Which units did you sell, the ones you 
> > > bought long ago, or the ones you bought recently? 
> 
> Linas,
> 
> I agree that you don't necessarily need a new account type to answer
> these questions.  

The above example deals with prices.  But the earlier email discussed
a different case: 'what about the cases where we have one or more
assets (possibly lumped into one account), whose value fluctuates, but
for which we don't want to/can't assign a price.  What does one do about
unrealized gain then?' 

> Although you _do_ need additional policy information
> for choices such as LIFO,FIFO 

right; and you this policy info will typically vary from account to
account.

> and you may want a flag to keep track of
> which units have been sold (for brevity of recomputation).

This problem of 'keeping track of lots' is an 'accounts-payable' type 
feature.  Even though there's no 'price', you want to be able to say 
'gee, I paid this bill, but not that bill. (not necessirly in date 
order).   The same concept occurs when filling shipping orders: 
'shipped these items, but not the rest of the order'.  Also for
spoilage.  The point being, there's a need for a generic mechanism of
this kind.

> That notwithstanding, with just a LIFO/FIFO flag and a "current price"
> you can compute all of the items you request: cost basis, realized
> gain (LT and ST), 

You need also a definition of where the data boundary between 'short'
and 'long' is.  It seems to vary country to country, and tax-season to
tax season.

> unrealized gain.  All of this computation can be
> done in a report.

Right, and it was, in gnucash 1.2.  Still surviving is src/engine/Queue.c
which implements a fifo, but this code isn't currently used anywhere.
(Its not 'rocket science', but its not 'trivial' either.  In terms of 
the complexity of the math, its easily the most mathematical of all of 
the code in all of gnucash, and this seems to impede understanding).

For me personally, this was one of the most valuable features of
gnucash, although I can't complain too loudly, as I am clearly in
position to do something about it.

> 
> The only thing that we _may_ want to change is something to keep track
> of how many units from a particular lot have been sold.
> 
> -derek
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available

-- 
I'm very PUBLIC-MINDED, I'm helping a NIGERIAN get his $25,000,000 back!