Corrupted reconciliation cannot be fixed?

Ken Heard kenslists at teksavvy.com
Fri Jul 17 21:19:13 EDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After reading the six threads on the list over the past year detailing
reconciliation problems it appears that if a reconciliation is
corrupted there is no way to fix it.  My problem however is different
from the problems cited in those threads.

When reconciling a bank account each month I have been using the
postpone feature in the reconciliation window after I have checked off
some of the transactions because I usually find others in the bank
statement which are not in the gnucash register.

Sometimes when I return to the reconciliation window I find that some
of the transactions I had checked off earlier are not still checked
off when I return to the reconciliation window.  I have to check these
ones off again.

I have also however found that transactions checked off to enable the
reconciliation for a given month to be complete appear as not checked
off when I open the reconciliation window for the next month.  To
complete the reconciliations for subsequent months I have to leave
those transactions unchecked.

For example, in the reconciliation for March of one of the bank
accounts there are three such transactions. These remain with an "n"
in the reconciliation column in the register instead of a "y".

Nevertheless these transactions had to be and were included in the
March reconciliation to succeed, but had to be remain unchecked for
reconciliations for subsequent months to succeed.  (There are also
other unchecked transactions which are legitimate.)  It appears that
there is no way for these three to be removed from the unchecked list;
they must consequently remain there forever.

I am wondering whether the way to avoid this phenomenon in the future
is not to use the postpone function at all.  Instead if I have to
leave the reconciliation to enter missed transactions I should simply
cancel the entire reconciliation and start the whole process over
again after any missed transactions are entered.

Thoughts anyone?

Regards, Ken Heard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlWpqZEACgkQlNlJzOkJmTfmywCeNypPzSKZ2Nol4oyAdwL+sE+o
u3sAn0dGLCkfSHZajQCSXnEP4g/pcp+4
=F6Ls
-----END PGP SIGNATURE-----


More information about the gnucash-user mailing list