Books, sessions [was: Re: UI independance]

Herbert Thoma tma at
Wed Apr 9 11:39:03 CDT 2003

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.
> 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.  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,
> in the SQL backend), and the balances where necessary are transferred to
> the "new" Accounts as Opening Balance transactions.  This has the
> benefit of reducing the amount of work needed to create the new "Book".

If you want to do it "The Right Way" from an accountants point of view,
you have to use the equtiy account IMHO.

Furthermoe I think there is a second problem with your "direct transfer
from old to new accounts" proposal: transactions have to be balanced.
If the two periods are in different files, the opening and closing
transactions point outside of the file which is not allowed and
you need the equity account anyway. This is not an issue if you have
all periods in one file or one DB.

> > > Advice, comments ...
> >
> > My advice is that we should optimize for SQL (either the Postgres or
> > the to-be-written embedded-MySQL Backends) and relegate the XML "File
> > Backend" to secondary (interchange) status -- then you don't have to
> > worry about all the issues that using XML files implies.
> >

I would not like to have a running Postgres DB server as a requirement for
GnuCash, but I think I like the embedded-SQL idea.

Herbert Thoma
FhG-IIS A, Studio Department
Am Wolfsmantel 33, 91058 Erlangen, Germany
Phone: +49-9131-776-323
Fax:   +49-9131-776-399
email: tma at

More information about the gnucash-devel mailing list