ANNOUNCE: Auto Cap Gains, alpha 1

Linas Vepstas linas at linas.org
Thu Aug 28 21:55:47 CDT 2003


On Thu, Aug 28, 2003 at 12:47:12PM -0400, Derek Atkins was heard to remark:
> linas at linas.org (Linas Vepstas) writes:
> 
> > > Also, have you tested how the end-of-period feature interacts?
> > 
> > Yes.  The bug-fixes in lots, and the cap gain support, is required
> > in order to have end-of-period work correctly.  So I've been staring
> > at that quite a bit.  But there may be some corner cases I haven't
> > really thought of. Although I thought I had ...  Again, testing/test
> > cases are needed.
> 
> Well, mostly I'm wondering if, e.g., paid/closed invoices get left
> behind, 

they get left behind, as long as they are not conencted to anything 
open through other transactions/splits. 

The opening balances are automatically computed for asset accounts,
zeroed for income accounts.

> and open invoices remain open? 

Yes.  But actually, I don't do any weeding of any of the business
objects.  Is it enough to sort transactions/lots/prices by date, 
and the business objects get dragged along for the ride?  Or do
I need to have special logic for those?

Hmm. Now that I think about it, book closing is broken for 
the business objects. e.g. I guess vendors/customers should be
treated like accounts: a copy in the new and old books.  The other
things, I'm not too clear about.

When I copy the account tree, I insert a pair of kvp-guid pointers
into each copy, so that if you are holding the new account, you can
find its 'gemini' twin in the older, closed book(s).  

There's a writeup in src/doc/books.txt but I'm not sure how well it 
provides an algorithm overview. I guiess that's another todo.

If you can provide a list of business objects that need to be copied
into old/new books, and another that can be sorted into old/new
by queries, that would be an important next step.  After that, routines
for copying, and a foreach iterator.  And a query based on date to
separate old and new.

e.g. for lots/transactions, I perform a query by date, but then
walk the lot-split-trnsaction (possibly cyclic) graph by hand 
to check for open lots, and weed accordingly.  (becuase writing a
do-it-all query seemed to hard ...)

> How is data copied across
> between new/old books?  Stuff like that...

Its moved, not copied.  Unless the two books have different backends, 
and then its copied/deleted.

> I'm not convinced we want to do this.  If anything I'd rather
> make a 1.10 release branch off HEAD rather than back-port this
> (and a lot of other changes) to 1.8.

I guess we'll have to see where the gnome2 port is when I get closer to
being done.

--linas

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


More information about the gnucash-devel mailing list