? Corruption of reconciliation history

Tue Apr 9 14:45:54 EDT 2013

On 4/9/2013 11:24 AM, Michael Hendry wrote:
> On 9 Apr 2013, at 16:03, Derek Atkins <warlord at MIT.EDU> wrote:
>
>> Hi,
>>
>> Michael Hendry <hendry.michael at gmail.com> writes:
>>
>>> I last reconciled my current account on 15th February, against a statement dated 5th February.
>>>
>>> Today I went to reconcile the same account against a statement dated 5th March, but the "Reconcile Information" window says:
>>>
>>> Statement Date: 05/02/2013 (UK date format)
>>> Starting Balance £4667.77
>>> Ending Balance £3533.65
>>>
>>> This Starting Balance is incorrect for either the 5/02/2013 or the 05/03/2013 statement.
>>>
>>> I opened the backup copy of the 15th February, and went to reconcile the account, and got the following in the "Reconcile Information" window:
>>>
>>> Statement Date: 05/03/2013
>>> Starting Balance £3158.20
>>> Ending Balance £4750.47
>>>
>>> These figures are what I expected to see when I went to reconcile the current file today.
>> GnuCash keeps track of the last two reconciled dates in the account
>> structure.  It uses this to compute the "next" reconcile date.  The fact
>> that the current file shows Feb 5 but your backup shows March 5 implies
>> that somewhere along the line you stopped using your normal data file
>> and started using a backup file from before the reconcilation.  This
>> kind of corruption cannot happen by any user action within the app, so
>> it implies to me you somehow forked the data file (which can happen if
>> you ever open gnucash by clicking on the datafile and you accidentally
>> clicked on a backup file).  You can detect this by looking at the actual
>> filename.  If you see something like the following:
>>  MyDataFile.20130219xxxxxx.gnucash.20130409xxxxxx.gnucash
>> then you've done this.
> Thanks, Derek.
>
> I'm not aware of ever having started up GnuCash by double-clicking a filename in the Finder, and can't find any files whose names match the example you give.
>
> I do have a number of files like this...
>
> MDH.gnucash.20130218095930.gnucash.20130409081929.log
>
> …but these were created today when I went through the backups, checking to find the most recent file which presented the reconciliation details correctly.
>
> If I understand the file-naming convention correctly, this is a log file created today (2013-04-09 at 08:19 hrs) of a backup file which was created on the 18th of February (2013-02-18 at 09:59 hrs).
>
>> As for the reconciled amounts, GnuCash does not store the last
>> reconciled balance; it's computed from the previously reconciled
>> transactions.  This means that if you accidentally change (or delete) a
>> reconciled transaction then it will throw off your starting balance.
>> Unfortunately how you correct this depends upon what change happened.
> OK. So if I overrule the Statement Date in the "Reconcile Information" window, this does no harm, and the "Starting Balance" figure is the real problem here.
>
>> If you just accidentally unreconciled the transaction (i.e., you changed
>> the description or some other non-number) then it's an easy fix -- you
>> run the reconcile and ignore the starting balance.  This unreconciled
>> transaction will show up in the list and you just re-reconcile it.
> Yes, I tried that, and didn't find any transaction which should have been marked as reconciled and hadn't been.
>
>> Alas, that's not as easy if you wound up changing the amount or deleting
>> the transaction.  And yes, it is possible to change the amount without
>> unreconciling the transaction!  Both cases will change the starting
>> balance but not leave any traces in the list of unreconciled
>> transactions once you get to the second stage of the reconcile process.
>>
>> Alas, the only way to fix this is to go through your history until you
>> find the errant transaction.
> This is what I feared! When you say "go through your history", is there a way of listing transactions that have taken place since a given date?
>
>>> The current GnuCash file seems to have the 5th Feb statement's
>>> transactions marked as reconciled (I haven't checked absolutely every
>>> one against the paper statement), and it looks as though whatever
>>> method GnuCash uses to keep track of past reconciliations has failed
>>> here.
>> I find it very odd that it would have the wrong date but also have those
>> transaction marked as reconciled.  Are you using a SQL storage?
> No, XML.
>
> I'm using GnuCash 2.4.11 on a late 2012 iMac 27" with OSX version 10.8.3, having previously used earlier versions on Ubuntu 10.04 and 12.04.
>
>>> I really don't want to have to go back to the 15 Feb backup, and
>>> re-enter everything!
>>>
>>> Is there some way of fixing this without going back to the 15 Feb
>>> backup and re-entering everything from then on?
>> It depends what's broken.  Some things are easier to fix than others.
>> The first thing I would recommend is Actions -> Reset Warnings…
> I wasn't aware of having turned them off, but they're turned on now.
>
> [Incidentally, the word "reset" is open to ambiguity here. The usual convention is for an entity which is turned on to be regarded as "set", and when turned off to be "reset", but in this instance to "Reset Warnings" appears to be to turn them on.]
>
> Michael
>
>>> Michael
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>> -derek
>>
>> -- 
>>       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 at MIT.EDU                        PGP key available
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
So far in this discussion I have not seen whether you checked the
running balance in the register view.  While the current balance changes
often, the current register balance as of the previous reconcile date
would only be different from the reconciled balance by the sum of the
few transactions that had not cleared yet on that date. 
Thus the register balance for Feb 5 in your 'last good' file should be
the same as in your 'current' file, or very close.  Looking further
back, say to December 31, the register balance should be the same in
both files unless the corruption is dated before that.  This sort of
search should help find the problem.

David C