Books, sessions [was: Re: UI independance]

Tue Apr 8 21:33:56 CDT 2003

On Sun, 2003-04-06 at 11:13, Derek Atkins wrote:
> linas at linas.org (Linas Vepstas) writes:
> 
> > I'd like to take these old comments as an opportunity to open a discussion
> > about the correct way to handle accounting periods.  There's (old) code
> > that will split a book into two, dividing up old and new transactions,
> > and putting them into separate books.  Now, with the new 'lot scrub', 
> > it is one step away from handling stocks accounts correctly.
> > 
> > But now the next problem arrises:  
> > -- do people want to look at several books at the same time?
> 
> Yes.
> 
> A better question is, what does this mean?  Personally, I'd like to
> _at least_ be able to have multiple files open (in different windows),
> sort of like how I can have multiple buffers in Emacs, or multiple
> files open in OpenOffice.
> 

Ditto.

> Similarly, I think that people MIGHT want to be able to run reports
> across multiple accounting periods, so it should be reasonable to do
> so (whatever that means).  The benefit of storing accounting periods
> in _different_ files is that when you don't want to run cross-period
> reports then you don't need to import the old data.
> 

and it helps manage file size. ;)

> > -- should I store multiple books in one file?
> 
> See above about limiting file size..  I don't have a strong
> preference.  However, a big part of me would really like to relegate
> XML to an interchange format and not a data storage format..  So
> trying to optimize for XML might not be a good idea, but YMMV.
> 

XML really isn't all that efficient as a dynamic data store.  It is,
after all, a *markup* language, and as such is highly adaptable to data
transfer and transform.  Storage...not so much, IMO.

> > -- if they get stored in multiple files, what is the naming 
> >    convention?  If people screw with the filenames, gnucash might
> >    not be able to automatically find  older books.

This is true.  How about, let people specify the files in a file
selection dialog, when they want to run reports spanning multiple
periods/files.  Of course, provide default names...

> > -- should I put several books in one session, or one session 
> >    per book?  Maybe it should be one session per file ??
> 
> That's a very interesting question.  Currently there is a 1:1
> relationship of GNCSession* <-> GNCBook*; if we plan to change that
> then a lot of other assumptions will have to change.  Note that I'm
> not arguing either way, I'm just pointing out an issue with changing
> it.  Personally I think a GNCSession should be tied to a file/db/etc.
> and GNCBook tied to an accounting period within that file/db/etc.
> 

I think we should define our terminology.  In my world, a "Book", or set
of books, indicates a collection of accounts.  These accounts are
persistent across accounting periods.  Occasionally, an account becomes
obsolete, and can be dropped when the period is closed (e.g., you pay
off your truck, so a Liability becomes obsolete).  Occasionally,
accounts are added (e.g., you buy a new boat on credit), and will appear
in this and future periods.  Other accounts are permanently persistent
(e.g., Expenses:Groceries--permanent at least for the lifetime of the
person!!).

Further, in my world, a Period represents a set portion of time during
which the Books are tracked.  A Period may or may not be closed (e.g.,
you'll want to run quarterly or monthly or periodly reports, but you
don't want to close out the books until the end of the larger period--an
accounting year).  Some of this is available in current reports by
setting the date range.  When you "close the books" for a period,
certain account types are reset to a zero balance.

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

> > -- The SQL backend does not have this complexity of considerations:
> >    all books are stored in the same DB, this is reasonable, since
> >    the SQL 'select' capabilities make this simple.  So the
> >    session/book correspiondence should work for files backend and 
> >    sql backend, and that is where the rub is.
> 
> Well, if we decide to relegate the file backend to a secondary storage
> then the rub doesn't matter ;)
> 
> But this brings up an interesting terminology issue.  By "book" do you
> mean "Set of Accounts" or do you mean "accounting periods"?  When you
> say "all books are stored in the same DB" do you mean that
> e.g. multiple companies would use the same DB, or that each company
> would have its own DB and just store all the accounting periods in
> that DB?  I _think_ you mean the latter, but we should probably choose
> the terminology that makes this distinction clear.
> 

I personally would prefer "Period" to indicate a chunk of time, and
"Book" to indicate a set of accounts that are measured for a given
entity (e.g., husband, wife, company...).  I haven't looked to see how
hard that is to bring the code in line with that, though...perhaps sed
could be used, or perl, to change all "GNCBook" to "GNCPeriod"... ;)

> > 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 second that emotion.  I have noticed, however, that the BookList seems
to be the future with Sessions.  If a bunch of files were "loaded" into
the BookList (1 file per entry), or if multiple database rows were
loaded into the BookList, I think what would remain is to have access
methods for the closed Books.  That is, you could use the existing
methods, but it looks to me that most of the Book access/update methods
restrict themselves to the "open" Book and ignore the others.  That's
probably an incomplete assessment, but is something that should be
double-checked.

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