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

[Derek Atkins]

The real problem is that we do not track individual widgets in the
"stock" accounts.  The reason this is _THE_ problem is that everything
else would fall out if it were solved.  Assuming we solve this
problem:

1) when you close a book, you only need to copy the unsold widgets
into the new book

2) it's the time-frame between buying and selling any individual
widget that makes Cap-Gains.  Don't forget that different places have
different cap-gains rules.  For example, in Massachusetts it matters
how long you hold an asset, and you are taxed differently for holding
it for <1, <2, <3, <4, <5 and >6 years!

3) a business "inventory" solution would fall out as well (because you
do need to track individual widgets).

Unfortuately I'm not sure how to really solve this problem, unless you
add information to the "sell a widget" transactions which point back
to the lot(s) that were (partially) sold.

-derek

Conrad Canterford <conrad@mail.watersprite.com.au> writes:

> On Tue, 2002-04-16 at 11:57, Linas Vepstas wrote:
> > Needless to say, storing extra stuff in the file format/database is 
> > a real pain in the butt.  SO the easy way out would be to automagially 
> > access old books, under the covers, whenever a report needed old data.  
> > Maybe not a performance win, but ... hey.
> 
> I realise that it is sort-of defeating the purpose of closing books, but
> maybe some types of "account" should be flaged to be duplicated into the
> new book complete?
> I'm particularly thinking that stock accounts would seem a prime
> candidate for this, as would inventory accounts (if we ever get such
> beasts), account payable/receivable accounts, and possibly others as
> well. Any time where the individual transaction is the important data,
> not necessarilly the total (final) balance.
> A further step on from this might be to have some sort of flag (or maybe
> using the reconciliation flag?) to indicate if a specific transaction
> needs to be duplicated. For example, Accounts Payable transactions that
> have been paid don't need to be duplicated, but the ones still
> outstanding really do need to be. Culling the "used" transactions would
> reduce file size without sacrificing the essential data.
> 
> I'll confess I haven't thought through all of the implications of doing
> this - either from an accounting point of view or from a
> gnucash-data-management point of view. At this stage, I'm just posing
> the question - could this be a viable approach? Would it solve the
> issues being discussed?
> 
> Conrad.
> -- 
> Conrad Canterford  (conrad@mail.watersprite.com.au)
> Water Sprite Pty Ltd   |  url - http://www.watersprite.com.au/
> GPO Box 355,           |  - Australian Tour and Event Management (ATEM)
> Canberra, ACT 2601     |  - Ticketing Division.
> Mobile: +61 402 697054 |  - Catering Services Division.
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available