Multiple books in file backend?

[Derek Atkins]

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".

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

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available