[grisbi-bugs] [Grisbi 0001514]: Reconcile history wrong, cannot reconcile

Grisbi Bug Tracker bugtracker at grisbi.org
Fri Mar 22 00:17:58 CET 2013

A NOTE has been added to this issue. 
Reported By:                stephane.gourichon
Assigned To:                pbiava
Project:                    Grisbi
Issue ID:                   1514
Category:                   Main
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     assigned
OS:                         Ubuntu 
Unstable Impact:            Yes 
Version OS:                  
Version GTK:                 
Date Submitted:             2012-08-08 18:18 CEST
Last Modified:              2013-03-22 00:17 CET
Summary:                    Reconcile history wrong, cannot reconcile
We used Grisbi for years with 6 accounts, manual typing of all operations,
reconcile regularly.

We now observe that reconcile fails on one account due to wrong initial balance
(92,44 instead of 90,60).

Steps to Reproduce: 
* Open account file ( account file not included here due to bug
http://www.grisbi.org/bugsreports/view.php?id=1512 ).
* Observe correct balance (13090,60) (see first attached image) and initial
balance for reconcile to come (90,60).
* Try to reconcile. Observe bad initial balance (92,44 instead of 90,60) (see
second attached image).

Additional Information: 

We used Grisbi 0.5.9 on Mac OS X for years.
Recently we switched to Ubuntu Linux and use Grisbi 0.8.8 from official Ubuntu

Bug looks like bug http://www.grisbi.org/bugsreports/view.php?id=1246 (and maybe
bug http://www.grisbi.org/bugsreports/view.php?id=1470).


 (0003479) stephane.gourichon (reporter) - 2012-08-08 19:40
When looking at the gsb file, I can't correlate the reconcile history with the
transaction history. The transaction history looks good, while the reconcile
history seems to contain whimsical balances. Especially, the last reconcile that
changes from 90,60 to 92,44 does not make sense. There *is* a transaction of
1.84 but it is marked as already reconciled, so should not be reconciled again.

See attached file extract_from_gsb_file.txt

I'm afraid that removing the bad reconcile line might break thing. I'll try to
just change manually the final balance (and date) to see if I can go on using
the software.

The important part here is : seems I'm not alone in having such a problem.
Grisbi will be better if the origin of this bug can be tracked and fixed. I can
provide additional information, just ask precisely what you need. I have kept
several intermediary backup files (which have same history inside) and the old
account file of version 0.5.9, which is obviously in a very different format.

I noticed that the last operation (of 1.84) inserted on that account has date
2012-12-31 which is wrong (don't know if it was indeed the date entered

The bug might be that the conversion from old format to new format made
assumptions like "no new operations is ever inserted on a date older than date
of last reconcile". That assumption is false here since last operation (+13000)
has date 2012-04-10.

That makes a lot of information, I tried to provide every useful hint. Thank you
for your attention and keep the ball rolling. 

 (0003484) c.schroeder (reporter) - 2012-08-18 22:04
Just encountered this bug with one of my accounts in v0.8.7.  Upgraded to
v0.8.8, but the problem persists.

In my case, the last reconciled transaction amount is correct, but it is not
being included in the initial balance for the next reconcile task, so there is a
variance equal to this last reconciled transaction.  My first thought was to
mark the offending transaction as unreconciled and then simply re-reconcile it,
but I cannot find any method in the GUI to accomplish this.  Also of note, the
transaction in question is a transfer between accounts.  The corresponding
transaction in the other account does not share this problem.

Last data point is the account in which this bug has occurred is a savings
account with infrequent transactions and has not needed to be reconciled for
several months. 

 (0003583) Richard42 (reporter) - 2012-12-30 20:28
I have also been living with this bug for over 2 years.  When I go to the
'reconcile' view, it shows a correct last reconciled date/balance of 2012-12-14
/ $16279.54.  However in the status bar of the Transactions view, it shows an
incorrect Reconciled balance of $16354.54.  The difference is $75.  There are 3
transactions, dated 2012-05-17, 2010-06-15, and 2010-12-15, each with a value of
$25.  These transactions are always in my transactions view (which I don't
want), because their status is neither P nor R - they show up as un-reconciled. 

 (0003614) c.schroeder (reporter) - 2013-02-21 22:33
Last Reconciliation lost in current account, but all transactions still in the
register and marked 'R'.  This makes for a *huge* variance.  This problem needs
to be resolved!  Will update from 0.8.8 to 0.8.9 to see if that makes any

 (0003625) c.schroeder (reporter) - 2013-03-22 00:17
I found my "lost" transactions!  I dug into my .gsb file and discovered in both
cases the problem was with the reconciliation dates.  In one case, I had
transposed the month and day numbers, causing the Idate to be later than the

In the second case, I had a typo in the year (2013 instead of 2012), causing the
fdate of the last reconciliation for the account to be later than the current
date.  Consequently, this reconciliation was not displayed as the last completed
reconciliation, thereby causing a large variance when attempting the next

Looks like some improvements are needed for reconciliation date checking. 

Issue History 
Date Modified    Username       Field                    Change               
2012-08-08 18:18 stephane.gourichonNew Issue                                    
2012-08-08 18:18 stephane.gourichonFile Added:
2012-08-08 18:19 stephane.gourichonFile Added:
2012-08-08 19:40 stephane.gourichonNote Added: 0003479                          
2012-08-08 19:47 stephane.gourichonFile Added:
2012-08-18 22:04 c.schroeder    Note Added: 0003484                          
2012-08-19 21:33 pbiava         Assigned To               => pbiava          
2012-08-19 21:33 pbiava         Status                   new => assigned     
2012-12-30 20:28 Richard42      Note Added: 0003583                          
2013-02-21 22:33 c.schroeder    Note Added: 0003614                          
2013-03-22 00:17 c.schroeder    Note Added: 0003625                          

More information about the bugsreports mailing list