The real problem is that we do not track individual widgets in the "stock" accounts. The reason this is _THE_ problem is that everything else would fall out if it were solved. Assuming we solve this problem:
1) when you close a book, you only need to copy the unsold widgets into the new book 2) it's the time-frame between buying and selling any individual widget that makes Cap-Gains. Don't forget that different places have different cap-gains rules. For example, in Massachusetts it matters how long you hold an asset, and you are taxed differently for holding it for <1, <2, <3, <4, <5 and >6 years! 3) a business "inventory" solution would fall out as well (because you do need to track individual widgets). Unfortuately I'm not sure how to really solve this problem, unless you add information to the "sell a widget" transactions which point back to the lot(s) that were (partially) sold. -derek Conrad Canterford <[EMAIL PROTECTED]> writes: > On Tue, 2002-04-16 at 11:57, Linas Vepstas wrote: > > Needless to say, storing extra stuff in the file format/database is > > a real pain in the butt. SO the easy way out would be to automagially > > access old books, under the covers, whenever a report needed old data. > > Maybe not a performance win, but ... hey. > > I realise that it is sort-of defeating the purpose of closing books, but > maybe some types of "account" should be flaged to be duplicated into the > new book complete? > I'm particularly thinking that stock accounts would seem a prime > candidate for this, as would inventory accounts (if we ever get such > beasts), account payable/receivable accounts, and possibly others as > well. Any time where the individual transaction is the important data, > not necessarilly the total (final) balance. > A further step on from this might be to have some sort of flag (or maybe > using the reconciliation flag?) to indicate if a specific transaction > needs to be duplicated. For example, Accounts Payable transactions that > have been paid don't need to be duplicated, but the ones still > outstanding really do need to be. Culling the "used" transactions would > reduce file size without sacrificing the essential data. > > I'll confess I haven't thought through all of the implications of doing > this - either from an accounting point of view or from a > gnucash-data-management point of view. At this stage, I'm just posing > the question - could this be a viable approach? Would it solve the > issues being discussed? > > Conrad. > -- > Conrad Canterford ([EMAIL PROTECTED]) > Water Sprite Pty Ltd | url - http://www.watersprite.com.au/ > GPO Box 355, | - Australian Tour and Event Management (ATEM) > Canberra, ACT 2601 | - Ticketing Division. > Mobile: +61 402 697054 | - Catering Services Division. > > _______________________________________________ > gnucash-devel mailing list > [EMAIL PROTECTED] > http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
