Recursive QofBooks
Geert Janssens
janssens-geert at telenet.be
Sat Aug 13 03:23:27 EDT 2011
On zaterdag 13 augustus 2011, John Ralls wrote:
> Along a similar vein, there's src/engine/period.[ch] and the "gemini"
> structure which depends upon it. The idea there appears to be that when
> one closes the books (in the accounting sense) at the end of a period, the
> book (in the Gnucash sense) also gets closed out and a new one is cloned
> from the old one.
>
> Users periodically ask for that and we tell them that that's not something
> we want to do, because the history gets broken up into several files. (It
> would work better with a proper DB backend like DBI, where the "new" book
> just means a new GUID on records and searches can span multiple books. For
> that matter, there's no reason an XML file couldn't also have several
> QofBooks in it. This could be made to work well with XQuery -- or even
> just XPath -- integrated into the XML backend.)
>
My first reflex would be to keep this code. I think being able to handle
separate periods is a useful concept. But thinking a bit deeper, it may not be
as straightforward as just using a new GUID to declare a new period/book.
A lot of objects are period independent: accounts, owners, tax tables,...
So if you change periods by changing books, you will either loose all these
objects or have to copy them over. Neither is really desirable.
I can imagine two alternatives that do a better job:
- add a period field to those objects that are period dependent (transactions,
splits, lots,...) and use that to filter period related information.
- define another container kind of object for periods that would contain all
period dependent objects per period. Something like
/book
/accountA
/accountB
/vendorA
/...
/periodA
/transA
/transA'
/periodB
/transB
/transB'
> If we really don't want to do that, we should rip out all of that code so
> that it doesn't have to be included in the "transactional" redesign.
>
I haven't looked at the code, so I don't know if it would make sense in either
of the above schemes.
If not, IMHO you can also just rip it out.
Geert
More information about the gnucash-devel
mailing list