Re: libgda vs. gnucash [was Re: GnuCash page on GO site]

[linas linas org (Linas Vepstas)]

On Thu, Mar 04, 2004 at 09:17:14PM +0100, C. Gatzemeier was heard to remark:
> Am Donnerstag, 4. M?rz 2004 17:26 schrieb Linas Vepstas:
> 
> > > > One that has been dogging me is the correct way to split up
> > > > a dataset across multiple files.  GnuCash startup time takes
> > > > a long time if you have a large data fileset.  So I would like
> > > > to split it up, while still allowing queries over older data
> > > > in older files if the user needed that.
> 
> > (Note that the "date sort" is a bad example, since the 2004 file
> > might need to contain transactions from 1999 to close out lots.
> > A 'lot' is a collection of named transactions pertaining to a
> > particular asset.  So the actual sorting of which transactions
> > go into which file can be algorithmically complex).
> 
> Excuse me to break in here, AFAIK the tranditional and accountig method to 
> keep different subsequent datasets coherent is to define corresponding and 
> equal closing and opening transactions on the "borders" of of each period.
> Maybe this could help here, too. This "shifting" or sorting of actual 
> transaktions into a different preriod is a own book-keeping sub-task in the 
> german accounting standards, and involves making assumptions i.e of valueing 
> parts of lots etc.

Yes, that is correct.  Most of the recipients on this list don't
know about financial reporting periods, so I wanted to gloss over
those details and just call the whole operation "algorithmically
complex".  

None-the-less, the generic idea of "closing a book" needs to be
supported by the underlying database system as a generic operation
on a generic collection of persistent objects.  For example, in 
bugzilla, one may want to clean out old, fixed bug reports, and
move them to some archive.  The analogy doesn't stop there. 

If you split apart a bugzilla dataset into two, there are parts
of the dataset that are copied and parts that are not: for example,
in bugzilla, you'd want to make a copy of the list of compnents,
the list of projects, the list of component owners.  This is just
like in gnucash, where both the closed book and the open book get
copies of the account tree.  In bugzilla, you sort all bug reports
into the one or the other dataset, so bug reports == gnucash
transactions.   Fnially, in bugzilla, when you weed out all the old
fixed bugs, you should not reset the bug numbering back to zero. 
You should continue numbering your bugs from where you left off.
This is like the "algorithmically complex other stuff" that 
gnucash does to close out book. 

While I'm not done implementing accounting period closing in gnucash,
I wanted to emphasize that I really do hope to implement it as 
a generic "database" operation in QOF rather than as something
specific to financial objects.  Of course the devil is in the details,
and that may not be practical.


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