CVS HEAD - trying to fix

[Neil Williams]

On Monday 08 November 2004 5:21 pm, you wrote:
> #1:
> > Invoices are posted to the accounts with gnc_numeric_zero values, despite
> > having an amount set in the entries.
>
> I wonder if this is due to Linas' new scrub code?  This certainly
> sounds like a bug in his scrub code.  That's certainly the most recent
> change, and I do know this USED to work.

All these errors were found in CVS exported for 2004-08-18 - there is a 
Changelog entry for Scrub.c dated 2004-07-20 so I'll investigate that.

> #4:
> > Unposting an invoice also causes the BillTerm entries to become invalid
> > AND unfixable in the GUI.
>
> "unfixable"?  What do you mean by that?

i.e. without hand-editing the XML, the invoice cannot be posted, edited or 
amended - it refuses to post because of a lack of billterms and the billterms 
themselves cannot be edited - it's greyed out. The 'Unpost' dialog is also 
quite different to current 1.8.9 and has extra features that need to be 
investigated. Problem #4 has not been investigated as deeply as the others, 
it may be a consequence of other problems.

> #7:
> > I also get Orphan-GBP created in every file - old, working files as well
> > as new - every time I view any account. I can see how Scrub.c creates the
> > file, cannot see why it does so.
> > Payments also get reset to zero amounts, no trace of the original payment
> > amount is stored.
>
> This also sounds like another bug in the Scrub code.

This is better, it's coming down to a small number of areas, not separate 
areas for all 7 problems. That's good news for me.

> > My remaining problems with my own code are:
> > 1. AccountGroup - need to find a way to retain groups after a merge to
> > complete the druid-merge code. Other improvements are also overdue for
> > the main merge routines.
>
> This is definitely important.  :)

It's a case of prioritising.

> It effectively means the merge isn't doing anything because my resulting
> CoA doesn't have any results from the merge.  IMHO you should just
> special-case the root AccountGroup (read: break the QOF abstraction) and
> move on.

Let me clarify. I am special-casing the root Account Group and the new 
accounts DO show up in the CoA (that's the effect of my most recent patch). 
The problem is with sub-accounts like Childcare or Federal Tax - the 
accountgroup Expenses or Tax is not being identified and because it cannot be 
abstracted at the moment, there's nothing in the merged book to cope with the 
new group. End result is that all new accounts appear in the CoA BUT they 
appear as top level. This will be dealt with in the druid-merge.c code rather 
than in QOF itself, so as long as I can identify which accounts should be top 
level and which should not, I'll solve it.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20041108/b8d2d564/attachment.bin