Book clsoing [was: Re: Addition of HBCI support, Maturity of 1.7-branch, next stable release time frame?

[Michael T. Garrison Stuber]

Is there going to be special support for Stock transactions?

--On Monday, April 15, 2002 02:58:24 PM -0500 Linas Vepstas 
<linas@linas.org> wrote:

> On Sat, Apr 13, 2002 at 06:46:48PM -0700, Josh Sled was heard to remark:
>> On Thu, Apr 04, 2002 at 06:02:56PM -0600, Linas Vepstas wrote:
>>
>> | I think the engine side is 'mostly' done, althought I have *not*
>> | handled SX's for book closing.  The big, big hole is to put together a
>> | GUI to allow the user to do this.
>>
>> Can you illuminate how book closing is going to occur, technically?
>
> src/doc/books.txt  'plan A', I beleive.   I should modify that do to
> indicate what actually got coded.
>
> Very very breifly,
> -- a copy is made of the account tree
> -- transactions are moved to the new account tree if they are
>    newer than date 'x' (actually, *any* valid query can be used
>    to partition the transactions into two sets, not necessarily
>    a date query).
> -- A balancing transaction is automatically added (between an
>    equity account and the current account). The trasnaction is for
>    the balance when the book got closed (so that new books start with
>    the right balance).
> -- Lots of kvp data is written out to indicate which new account is a
>    copy of which old account, what the closing date was, etc. etc.
>    In theory, there is no data loss.
> -- changes to SQL DB & XML backend to support the sorage of multiple
>    books.
>
> Most of the 'hard work' in coding this was to update/cleanup how
> books and guid's and entities interact, so that I could have multiple
> books going at once.  (This is actually an area where I had problems
> with sched xactions, since it assumed that there is one unique account
> group, when in fact there is one account group per book.)
>
> Remaining work, besides providing a GUI, is to modify searching,
> graph generation, reports, etc. so that they can work over multiple
> books (or not, user's choice).  I think this is important so that
> one could graph, for example, a multi-year trend line from data in
> multiple books.  (Never mind being able to run an 'annual report'
> even if one closed books monthly.).
>
> Hmm. Actually, I'm not sure how much I tested the XML backend. If at
> all.  I think I got hung up trying to figure out a suitable naming
> scheme for auto-naming the differrent books.
>
>
> --linas
>
>>
>> ...jsled
>>
>> --
>> http://www.asynchronous.org - `a=jsled; b=asynchronous.org; echo
>> ${a}@${b}` jabber:jsled@jabber.asynchronous.org, ICQ:4983267,
>> {AIM,YIM}:joshsled
>
> --
> 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel