Books/Accounting Periods proposal

[James LewisMoss]

>>>>> On Fri,  6 Apr 2001 19:26:51 -0500 (CDT), linas@linas.org (Linas Vepstas) said:

 Linas> Plan A: ------- The kvp markup of plan C coupled to the
 Linas> multi-file solution of plan F.  In initial startup of gnucash,
 Linas> only the 'current' book is loaded.  If user asks for a report
 Linas> that requires data from old books, then we have to pause to
 Linas> load one or more of the older books.

 Linas> If the books are stored as separate files, then the 'current'
 Linas> book needs to somehow know the filenames of the old books.  I
 Linas> recommend against storing the books as different sections of
 Linas> one file, for many reasons:
 Linas>  % risk of corruption of old books bloated file size the
 Linas>  % single-file solution would need to invent a 'directory' so
 Linas>    that the location of the old books in the file can be
 Linas>    quickly found and lseek()'ed or mmap()'ed.  But why invent
 Linas>    a directory? Unix already provides directories!

 Linas> I recommend that every book get a unique guid.  The current
 Linas> book would know the guid's if its closed book progeny.  The
 Linas> filename would incorporate some compressed version of the guid
 Linas> (and/or the date of closure).

 Linas> Optional: every book gets not only a unique guid, and also
 Linas> stores some meta-information (as book-level kvp's):

 Linas> /book/name=some-user-supplied-name
 Linas> /book/notes=user-supplied-descriptive-comments
 Linas> /book/start-date=xxx /book/end-date=xxx
 Linas> /book/previous-book-guids=(list 0xa 0xb 0xc)
 Linas> /book/accounting-period=enum {none, week, month, quarter,
 Linas> trimester, year}

 Linas> I don't know if the latest XML format provides for top-level
 Linas> 'global' data: but in principle, a top-level kvp is enough?

Not at the moment, but it's a 5 minute job to add.  (5 minute being
programmer time more like 4 hours real time :)

 Linas> Pro's & Con's ------------- I am not aware of any con's to
 Linas> plan A at this point.


 Linas> Implementation Notes: --------------------- Plan F is the
 Linas> easiest to implement: a few days to a week; maybe two weeks if
 Linas> gnc-book.c needs serious overhaul.

 Linas> Plan C is mostly just as easy as F (writing out the kvp is
 Linas> near trivial).  The hard part of plan C is the wrapper/utility
 Linas> to allow searches of current and/or old books.  The wrapper
 Linas> could be delicate, and needs more thought.  Also, add another
 Linas> week to deal with the GUI tab/button to search 'current book'
 Linas> or 'all books'.

 Linas> Plan A is only a little harder than Plan C: maybe another week
 Linas> or two on top of C (??)

I like this as well.

This brings up something I was thinking.

It'd be nice to stop using "files" as such to save gnucash data.
Instead give the user a default path (which they can add to if they
like) and search for books on that path.

If they wanted to open a new book they'd say "New Book".  It'd prompt
them for a name and then handle all the file creation for them without
them having to pick a file name and location.

Pros: gives us the ability to easily do the above with a setup like
TestAccount/
TestAccount/Info
TestAccount/Year1999
TestAccount/Year2000
TestAccount/Current
TestAccount/config.options
TestAccount/DefaultReports
TestAccount/etc

Cons: takes control over the file setup from the user

What do people think?

Jim

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach