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

[Linas Vepstas]

On Tue, Apr 16, 2002 at 11:15:56AM -0400, Derek Atkins was heard to remark:
> > Tracking lots is the 'definition' of A/R and A/P.  You want to be able
> > to say that this bill is 120 days old, and its balance has been partly
> > paid off; and this whether or not there are also other bills, of
> > different ages, to the same company.   This is *identical* to tracking
> > lots of stock or widgets.  If/when you add A/R and A/P, you will 
> > defacto have a lot tracking system that is suitable for inventory.
> 
> Perhaps.  That's not the way the current A/R and A/P are implemented.
> While each transaction has a post date and a due date, there is no
> logic to see when a particular bill has been paid, and there is no
> support currently for partially-paid (or over-paid) bills.
> 
> But I don't see this as the same as inventory or stock tracking.

Hmm. It should be. Maybe the other email cleared this up, maybe not.
So I'll repeat and rephrase.

Imagine buying a 'lot' of 100 shares of stock in 1998.  Give this lot a
unique serial number so we can track it.  When we sell 50 shares years
later, we sell out of this 'lot number'. 

Inventory is essentially the same thing. We have unique lot numbers.
Whether we are counting shares or widgets doesn't matter.

True ar/ap is the same thing: the 'lot number' is now called the 
'bill number' or 'invoice number'.  And instead of saying that we bought
100 widgets in 1998 and sold 50 widgets in 2000, we say we incurred a
debt of $100 in 1998 and paid back $50 in 2000.  Under the covers,
the same mechanics apply.

How might this be represented in gnucash?  One (or more?) transactions
put things 'into' the lot.  Other transactions drain things out of 
the lot.  This part is easy enough.  In this sense, a 'lot' looks
like an 'account'.  (I repeat: This is a key concept: a 'lot' is a 
lot like an account.)  In other words, a 'bill' is 'paid off' when the 
'lot/account' balance is zero.  

(If the balance for the 'lot' isn't zero, then we say that the 'bill'
has been under/overpaid.  For stocks, we either have 'long term
holdings' or we have 'sold short against the box'.  When the balance
is zero, then we are 'no longer invested in that stock'. Etc. same
concept, different words.)

Its almost that simple, but not quite. Here's where it gets hard & wierd:

Imagine we buy 100 shares of stock in 1998, and 100 more in 1999, and
then I sell 150 in 2000.  In today's gnucash, this would be three
transactions.

With "true" ar/ap,  we have to split the third transaction between 
two lots.  For some display/reporting modes, you want to hide the fact
that its split, since you want to show the user that they sold 150
shares.  (which, for most users, is all they care about).  In other 
cases, when the user is browsing by lot-number, then you want to show 
the split explicitly.  

Hopefully, its obvious how this is similar to taking a loan for $100
in 1998, taking a second loan for $100 in 1999, and repaying all of the
first loan, and half of the second loan, in 2000.  Note that when we
phrase it this way, the user *does* care about how the $150 was split
between the two loans.  (Maybe they think they paid back $75 of the 
first loan, and $75 of the second loan ... ?)

Key implementation detail:  Its almost easy to implement lots.  They
look like accounts (aha!).  Every split would have a pointer that
says 'this is the lot I put into/draw out of'.  The friggin hard part
is the GUI that sometimes hides, and sometimes shows the splits that
are split accross lots (but are not split across accounts).   That
is the part where I don't yet see a simple solution to.


===============================
The other email points out that tracking a lot with only one item in it
is identical to tracking the item.   If you set up the currency
denominator so that its 1 instead of 100, then you guarentee that you
can't accidentally sell a fraction of one unit.

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