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

["C. Gatzemeier" <c gatzemeier tu-bs de>]

Am Freitag, 5. März 2004 15:55 schrieb Linas Vepstas:

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

I see, please let me know if i should not continue to CC other lists than 
gucash-devel.

Bugs may even be a little more complex compared transactions since they have a 
lifetime whereas transactions occur in one point of time. On the other hand 
this makes sorting out bugs easy (closed for x amount of time == old dataset) 
and accounting for transactions that occured in onother period than they 
belog to so hard. To do this additional and (according to external 
assumptions) varying information is needed that can not be derived from the 
data.  I would call this sorting activity that accountants do at the end of 
each accounting period "closing a period". And I would say it can not be 
implemented to be done automatically because it would never match the 
assumptions that are needed/required in a particular case. (Somthing like a 
wizard that supports the user in generating the closing transactions, asking 
about the choices he has for things like depreciation etc. however is 
possibe)

When you wrote about "closing a book" above and "period closing" below I am 
not sure if you do refer to different things.
Because I think it is better to separate those two functions. I assume 
"closing a book" to be the same as "splitting the data", (from the time when 
the data was kept in books (or the "book" in the XML file ;-) but different 
from closing a accounting period.


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

This pretty well assembles how I would like to think of "data splitting" or if 
you want "book closing". I would rather not call it book closing because this 
ambiguity that one easily thinks this would be the thing one needs to do 
every year or even quarter.


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

I see no general problem as this is only data splitting, and all information 
to split the bugs is contained in the data.


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

Concerning the problem of renaming or moving continious objects (accounts) and 
keeping subsequent datasets coherent: If a previous dataset exists, only 
empty accounts that also started with a zero balance should be allowed to be 
deleted (thus moved/renamed). (law of continuity)

 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.

It's the starting and ending balance. With bugs its easy since there is a hard 
criteria to move them into one of two periods. In accounting each regular 
transactions belongs only to one of those periods (determined by the date of 
occurance). BUT accountants want to slice continous time into periods and in 
some cases account for a transaction at another time to "correct" earnings.

Example: 500Euro rent for December 01 is not received until January 02, but 
this income belongs to the previous year (01). The regular transacion occurs 
in January and belong to  02, however to accout for it in 01 some closing 
transaction of 500Euros are made, the 500 hit rent earnings account, and will 
end up with 500Euros as miscs. assets in the closing balance account. 02 will 
than have a opening transaction from opening balance account to the misc. 
assets. The incoming money in January is then only a asset swap and has no 
effect on the earnings in 02.

This just, as a simple example. Depreciation(one cost transaction spread out 
in multiple periods) etc. make it so complex that it can not be done 
automatically and it would also be way too unflexible to have those things 
staticly in the datasets. Already the next internal accounting report will 
need to make different assumptions for those closing and opening 
transactions.
Separating the closing/opening transactions from the continous transaction 
data as described on the wiki should be relatively easy and also allow those 
things like overlaying different period definitons over the same base of 
continous transaction data.

Regards
Christian