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 02:13:30PM -0400, Derek Atkins was heard to remark:
> I guess it depends what you mean by ar/ap, exactly.  


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 id (guid)
-- lot name (user supplied name or serial-number)
-- lot memo (free-form user-supplied text)
-- list of pointers to splits that belong to this lot
-- 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.

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

-- I don't know/haven't thought about whether we need different 
   'types' of lots.  e.g. does a lot need to indicate that its payable
   in 30/60/90 days and that there's a 10% discount for immeidate
   payment?  Or is this a separate feature stored in some other struct?


There's a zillion GUI issues, in how to best display this data.  But
at the core componenet model, I think that's it.


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