Finding Invoice Type "?" - Input needed on how to fix the damage done after the fact (Check & Repair update)

[Geert Janssens]

On Monday 18 January 2016 17:53:06 Geert Janssens wrote:
> On Thursday 14 January 2016 10:01:37 Benjamin Soffer wrote:
> > Geert,
> > 
> > 
> > 
> > Thank you for offering to inspect the subject data file.  The data
> > file is for a law firm and therefore, in some instances, it reflects
> > confidential client information which may not be revealed.  However,
> > I could send you a sanitized version, stripped of all data except
> > for
> > the messed up records and a few others.  Would that be sufficient?
> > 
> > 
> > 
> > Regards,
> 
> Benjamin,
> 
> I have looked at your data file just now. You said you can't find the
> missing invoices when searching for them in the gnucash program.
> Unfortunately I can confirm this is so because they are not even in
> the data file itself anymore.
> 
> I have no idea how this has happened and it's the first time I hear
> about this.
> 

A follow up.

I recently learned there is a bug report for this issue:
https://bugzilla.gnome.org/show_bug.cgi?id=754209

It explains how you can get into this situation: by trying to post an invoice that is already 
posted. One way to achieve this is via the "Find Invoice" search window. That's what the bug is 
about. That window has a post button, but won't check if the selected invoice(s) were posted 
already or not.

A fix for this bug will go into the next release (2.6.12). If I get to it I would also want to add 
some code to check and repair to fix the data if others happened to have hit by the same bug.

For the implementation, I have some kind of dilemma though:

* First off, know that "Check & Repair" does not communicate with the user. The current code 
can't and it would be a major redesign to implement that. Something that can't be done on the 
stable gnucash series. So "Check & Repair" currently changes your data without telling you 
what it has changed.

* That implies it should only make changes it knows 100% they are correct. Changes that need 
a user decision can't be made.

* For this particular issue, the right thing to do would be to remove the duplicated post 
transactions. Assuming I can correctly and safely identify them that is doable.

* However removing transactions will alter the balance. The user may not immediately notice 
this and there's no way the code can inform the user of this.

* That may be bad, because the user may already have entered a balancing transaction to work 
around the wrong balance caused by the doubly posted invoice. There is no way the "Check & 
Repair" code can discover this, because there is no clear link set by the code.

* Alternatively I could only make the bad transaction editable so the user can decide for 
him/herself whether and when to remove the bad transaction.

* That would preserve any balance as it is and leave it up to the user to go in and remove the 
bad transaction together with a possible counter transaction.

* Also here the code has no way to inform the user about this.

So what would be the best way to handle this ? Either one of these scenarios or yet another one 
?

Geert