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.