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!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
