Books, sessions [was: Re: UI independance]

Linas Vepstas linas at linas.org
Sun Apr 6 13:08:04 CDT 2003


On Sun, Apr 06, 2003 at 12:13:03PM -0400, Derek Atkins was heard to remark:
> 
> The query routines can already run against multiple GNCBook*
> objects...

Bravo!

> But this brings up an interesting terminology issue.  By "book" do you
> mean "Set of Accounts" or do you mean "accounting periods"?  

Yes.  The current book design assumes that all transactions are between
accounts in the same book, there are no cross-book trnasactions.

When splitting a book into two, the accounts are cloned, and a copy placed
in each book.  The allows dead accounts to be pruned from the new book,
without killing them in the old book.   The accounts are annontated with 
KVP's so that one can trace the clones to each other.

One cannot store more than one accounting period in a book, thus books 
are 1-1 to accounting periods.  Similarly, one can only store one set 
of accounts in a book, so these are in 1-1 relation too.

The KVP annotation that identifies cloned accounts across different 
books can be thought of as a kind of meta-set-of-accounts that transcends
multiple books, but there is no high-level, master dedicated structure
that holds the set-of-accounts-for-all-time.  (and that's good, I think).

> 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'm not sure what you mean by 'company'.  

I certainly run multiple gnc files: one that lists expenses owed me by 
my employer, another that lists money spent on the car, a third that
summarizes net worth.  I have no desire to meld these together in any
way; each acheives a certain purpose simply and cleanly. 

I'd hate to call these different 'files', 'companies'.

I'm concerned, as per earlier thread, that the addition of new 
business features is shifting the terminology to business terms,
which can cloud up issues, as per earlier thread.

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933


More information about the gnucash-devel mailing list