Multiple books in file backend?

Matthew Vanecek mevanecek at yahoo.com
Sun Aug 3 21:03:16 CDT 2003


On Sat, 2003-08-02 at 13:47, Derek Atkins wrote:
> Matthew Vanecek <mevanecek at yahoo.com> writes:
> 
> > On Wed, 2003-07-30 at 21:39, Linas Vepstas wrote:
> > > Anyone have any opinions about the right way that books 
> > > & sessions & backends should be associated?  I have to be
> > > able to handle saving (and eventually opening) multiple
> > > books.  If no one cares, I'll just invent something,
> > > otherwise, now is the time to speak.
> > > 
> > > --linas
> > 
> > My understanding of the way it should work (in theory), is that a
> > session represents a slice of time during which GnuCash is up and
> > running.  A session can operate on multiple books from multiple backends
> > (albeit not simultaneously).  A file backend would necessarily separate
> > 'books' into different files (where a single book could contain 1:N
> > Periods, with the largest Period traditionally being a financial year
> > and representing the scope of the book).  This of course creates more
> > work for the user: "Close the books for 1999? (yes) Enter File Name for
> > Old Data: (1999.xac)".
> 
> I dont have a strong opinion of how it should work, but I certainly
> have a few things that should be supported.  Obviously a single Period
> must be contained within a single file, however I'd also like the
> ability to have:
> 
>         - multiple Periods in a single file
> AND     - multiple Periods split across multiple files
> 
> Beyond this I have no strong opinion.  I'd like the user to be able to
> decide whether a new period should go into a new file or the same file
> -- however I dont know how to do that in a way that is UI-consistent
> with, say, a SQL database.
> 
> > An SQL backend creates other possibilities, and much of the work of
> > remembering file names is removed from the user: "Close the books for
> > 1999? (yes) Books Closed!".
> > 
> > In either case, a new account tree must be created that duplicates the
> > original account tree, that is used to populate the new book with
> > (which, I believe, is already implemented).  Account balances, etc., for
> > asset/liability/whatever accounts need to be moved over...but you
> > already know that, so I'm just rambling...
> 
> Yep, but I think this already exists...
> 
> > I would also like to point out that someone (I think you) mentioned that
> > closed books should be uneditable.  There should be a (configurable)
> > time period during which edits to closed books are allowed.  The company
> > I work for (and most others, I imagine) have a time period after a
> > period close during which journal entries, etc., are finalized.  Just a
> > thought/suggestion...
> 
> This is called "the 13th period".  Basically what it means is that you
> can create a period that happens "after Dec 31st" and "before Jan
> 1st".  Any transactions that have to happen in the "current year" can
> go into the "13th period".
> 

I think that would be based on accounting preferences, wouldn't it? 
What I meant above was, there is a deadline by which all adjustments to
the previous period have to be made, not that there something like your
13th period.  Once the deadline has passed, accounting has to go through
hell-n-high water to change something in a closed period, but up to the
deadline, it is still editable.  They are very picky about it, too.  I
supported some of the systems that fed the accounting systems, and if
something went wrong that might affect a deadline, we were damn sure
going to work 24/7 to fix it...

Evidently, since you brought it up, there must also exist your concept
of the 13th period.  So, accounting preferences.  As long as the tax man
can be satisfied, and your partners/share holders...

Perhaps you can open a new set of books without closing the old one, and
then at some point, click the "Close This Book" button to close it and
make it un-editable...

> So, I still believe that closed periods should be read-only..  However
> I believe periods should not necessarily be tied to dates.
> 

How do you get around tying a Period to dates?  I'm not thinking
set-in-stone dates, of course.  Users should be able to configure custom
Periods that cover a custom date range.

What else were you thinking they could be tied to?

-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...



More information about the gnucash-devel mailing list