Books, sessions [was: Re: UI independance]

[Matthew Vanecek]

On Sat, 2003-04-12 at 18:17, Linas Vepstas wrote:
> On Wed, Apr 09, 2003 at 10:39:03AM +0200, Herbert Thoma was heard to remark:
> > Matthew Vanecek schrieb:
> > <...>
> > > I can see two ways to implement this.  You could simply create equity
> > > transfers to a "Zero the Account" equity account.  This is currently
> > > available, and is also quite tedious (unless a way were implemented to
> > > automate it).  It is also, well, kludgy.
> 
> Again, I'm not sure of teh context.  The current code, when splitting 
> one book into two books, makes a copy of the accounts.  The opening balances
> in asset accounts in the 'new' book are in fact transfers to an equity account.
> Income/expense accounts are simply zeroed (they do not need an opening balance;
> this is part of the "magic" of the concept of the equity account).
> 

This essentially is what I meant with the second implementation I
described.  You just have a clearer way of explaining it, it seems. =P

> > > The other way is similar to what's already implemented, although I would
> > > like to see the terminology change (which is probably too difficult to
> > > be worth it, so relegate that to a pipe dream).  As you've mentioned,
> > > clone the accounts into a new "Book", where a "Book" is actually a
> > > Period.  
> 
> I wanted to distinguish books from periods, as they are inter-related, but 
> not the same thing:  a 'book' holds the chart of accunts & etc.  
> A 'period' holds a set of dates, info about the periodicity of the
> closing of books.  
> 

That's good, then.  To achieve a certain amount of granularity in
reporting (as well as ease of calculation), it would be beneficial to
have a GNCPeriod object, that describes a given period of time (e.g.,
quarter, week--my company uses a 13-period year...).  I don't have a
crystal clear vision, but I'm thinking something where a transaction (or
a split, or an account balance) is tagged to a given GNCPeriod, where
that GNCPeriod can be the child of another GNCPeriod.  There would be
issues--e.g., can parent GNCPeriods have transactions, or would all
transactions/splits/whatever be force to attach to the most granular
GNCPeriod available?

> The point being that a book can be split into two along lines other than
> merely a dividing date; *any* search criteria (any valid return from the
> query subsystem) can be used to used to parition a book into two.  
> Furthermore, some users may not want to close books on a periodic basis, 
> but rather, on an ad-hoc basis (e.g. project completion).  In this case,
> calling it a 'period' would have been truly confusing. 
> 

That's true.  I had a thought that periods would be customizable, which
may be helpful with ad-hoc.  I'll have to think on it some more...

> > > However, IMO, the current implementation is a little backwards
> > > when dealing with the GUIDs.  It should create clones of the Accounts,
> > > where the new Accounts have new GUIDs and are for the new Book
> > > (Period).  The "old" Accounts are moved to the old file (or left alone,
> 
> When I clone the chart of accounts, I needed to make sure that the two clones
> had different GUID's.  I forget whether the 'new' or the 'old' accounts got 
> the new GUID's.
> 

>From what I could see, the "old" accounts got new GUIDs.  It's probably
a nit-picky point, but I think it'd save some processing time to give
new GUIDs to "new" accounts, instead.  God knows, accounting
applications need every optimization possible!!!

> Whichever way it went, I had some vague reson for doing it that way.
> I don't remember it.  Its not documented, I don't think ?? (maybe in the code??)
> 

I didn't see any documentation for the reason--only for the action.

> I think you are probably right: its safer/better to have the 'old' guids
> stay with the 'old' accounts, and create new guids for the new accounts. 
> If you can think of some good reasons it should be one way or the other,
> this should get documented in the design-reequirements doc (src/doc/books.txt)
> 

Okie-doke.


-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...