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

Conrad Canterford conrad@mail.watersprite.com.au
17 Apr 2002 00:25:27 +1000


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  (conrad@mail.watersprite.com.au)
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.