Book clsoing [was: Re: Addition of HBCI support, Maturity of 1.7-branch, next stable release time frame?

Michael T. Garrison Stuber garrisonstuber@bellsouth.net
Tue, 16 Apr 2002 20:14:51 -0400


I'm confused by this.  I have some specific thoughts/questions below, but 
here is my basic concern:

	I'm thinking about this in terms of tracking stocks, and I'm taking you 
very seriously about lots being like accounts.  Let's assume that I have a 
stock account which I have purchase ten blocks of shares, each block being 
500 shares.  (No, I don't have that kind of money, but stay with me here). 
I decide I want to sell (or give, or whatever) portions of my holding. 
Since I have excellent records I am choosing to identify sets of shares for 
tax purposes.  Specifically, I decide to give 200 shares from my third 
purchase to my local house of worship.  I need to determine my basis for 
the 200 shares, as well as tracking my basis in the remaining 4800 share 
position.  How does this work?
	Do I have two lots? One for shares that are actively part of my basis, and 
one for shares that have been liquidated?  If so, what do I do about the 
fact that a split can have only one lot?
	Do I have one lot, for liquidate shares only?  Again, what do I do about 
selling 200 shares from a split in which I purchase 500 shares?
	Do I have a lot for every transaction?  (This only makes sense if lots 
aren't nearly as akin to accounts as I've assumed above).  Does a lot have 
a "remaining balance" or a "units liquidated" independent of the sum of the 
constituent splits such that I can track what I've sold from this grouping 
of splits?


> I'm concluding that the easiest thing to do would be to add 'lots'
> as a base type in the gnucash engine.   A 'lot' would be sort-of like
> an account:
> -- lot name (user supplied name or serial-number)
> -- lot memo (free-form user-supplied text)

Could/would these be created automatically on accounts which are set to 
track lots (assumes new account level flag)?  For example, I'd just assume 
that every stock purchase I make automatically have a lot associated with 
it, rather than having to go back and selectively build lots when I go to 
sell part of a security.  Or am I totally misapplying things?

> -- computed/cached flag indicating whether the balance on this lot is
>    zero or not.  If the balance is zero, then I know instantly that
>    this is a 'bill' that has been 'paid in full', and I don't have
>    to do any more math to proceed onwards.

Is there a balance for the lot itself?  It's nice to know whether it's zero 
or not, but, taking the stock example, I'd like to know how much I've sold 
out of a lot.  I could see the other option being to move the split from 
one lot to another, but this doesn't address selling part of a set of 
shares.  Well, I suppose you could go back and create two splits from the 
original split, and assign one to one lot, and one to another.  That seems 
pretty tedious.

> Next, every split needs a new field, pointing at the 'lot' to which it
> belongs. A split can belong to at most one lot. (or none).
>
> -- Unlike accounts, lots cannot be arranged heirarchically.
>    I also don't see any need to cache a runnning balance or anything
>    like that. (presumably, this can be computed on the fly).

Would you expect lots to be interated through directly, or only through the 
GUID reference from a lists of splits?

For example, if I'm writing a report to determine my current basis in a 
stock position, for every purchase I'd like to take the price paid for each 
share, multiplied by the number of shares remaining in that lot and sum 
that together.  (Of course, this doesn't address the commision itself, but 
we won't worry about that right now).  This also assumes that for stock 
reporting all splits connected to a lot would have the same share price.