Book clsoing [was: Re: Addition of HBCI support, Maturity of 1.7-branch, next stable release time frame?
Tue, 16 Apr 2002 17:21:27 -0500
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
-- 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.
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <email@example.com>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933