Books, sessions [was: Re: UI independance]

Linas Vepstas linas at
Sat Apr 12 19:17:12 CDT 2003

On Wed, Apr 09, 2003 at 10:39:03AM +0200, Herbert Thoma was heard to remark:
> Matthew Vanecek schrieb:
> <...>
> > I can see two ways to implement this.  You could simply create equity
> > transfers to a "Zero the Account" equity account.  This is currently
> > available, and is also quite tedious (unless a way were implemented to
> > automate it).  It is also, well, kludgy.

Again, I'm not sure of teh context.  The current code, when splitting 
one book into two books, makes a copy of the accounts.  The opening balances
in asset accounts in the 'new' book are in fact transfers to an equity account.
Income/expense accounts are simply zeroed (they do not need an opening balance;
this is part of the "magic" of the concept of the equity account).

> > The other way is similar to what's already implemented, although I would
> > like to see the terminology change (which is probably too difficult to
> > be worth it, so relegate that to a pipe dream).  As you've mentioned,
> > clone the accounts into a new "Book", where a "Book" is actually a
> > Period.  

I wanted to distinguish books from periods, as they are inter-related, but 
not the same thing:  a 'book' holds the chart of accunts & etc.  
A 'period' holds a set of dates, info about the periodicity of the
closing of books.  

The point being that a book can be split into two along lines other than
merely a dividing date; *any* search criteria (any valid return from the
query subsystem) can be used to used to parition a book into two.  
Furthermore, some users may not want to close books on a periodic basis, 
but rather, on an ad-hoc basis (e.g. project completion).  In this case,
calling it a 'period' would have been truly confusing. 

> > However, IMO, the current implementation is a little backwards
> > when dealing with the GUIDs.  It should create clones of the Accounts,
> > where the new Accounts have new GUIDs and are for the new Book
> > (Period).  The "old" Accounts are moved to the old file (or left alone,

When I clone the chart of accounts, I needed to make sure that the two clones
had different GUID's.  I forget whether the 'new' or the 'old' accounts got 
the new GUID's.

Whichever way it went, I had some vague reson for doing it that way.
I don't remember it.  Its not documented, I don't think ?? (maybe in the code??)

I think you are probably right: its safer/better to have the 'old' guids
stay with the 'old' accounts, and create new guids for the new accounts. 
If you can think of some good reasons it should be one way or the other,
this should get documented in the design-reequirements doc (src/doc/books.txt)


pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933

More information about the gnucash-devel mailing list