Books/Accounting Periods proposal

[James LewisMoss]

>>>>> On 07 Apr 2001 12:01:31 -0400, James LewisMoss <jimdres@mindspring.com> said:

>>>>> 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 quickly
 Linas> found and lseek()'ed or mmap()'ed.  But why invent a
 Linas> 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?

 James> Not at the moment, but it's a 5 minute job to add.  (5 minute
 James> 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 (??)

 James> I like this as well.

 James> This brings up something I was thinking.

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

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

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

Derek Atkins comments made me think of something more here.
This could make accessing backends easier as well.  Instead of the
files containing the real data they could be pointers into different
backends.

So
TestAccount/Info could be (using a pseudo format cause I don't want to
write xml right now)
Options: file:config.options
Reports: file:DefaultReports
SomeOtherThing: etc

Book: <guid>
Name: Year1999
Location: file:Year1999
ClosedOn: 1999-12-31

Book: <guid>
Name: Year2000
Location: file:Year2000
ClosedOn: 2000-12-31

Book: <guid>
Name: Current
Location: file:Current

or it could be
Options: file:config.options
Reports: file:DefaultReports
SomeOtherThing: etc

Book: <guid>
Name: Year1999
Location: postgresdb: localhost:Year1999
ClosedOn: 1999-12-31

Book: <guid>
Name: Year2000
Location: postgresdb: localhost:Year2000
ClosedOn: 2000-12-31

Book: <guid>
Name: Current
Location: postgresdb: localhost:Current

In the first example the files are there.  In the second they don't
exist. 

Of course this isn't meant to be the right data just an example.

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