[GNC-dev] About 3.9 and reconciliation balances

[David Cousens]

Chris,

1.  I am concerned that the "new method of calculating starting balances"
introduced in GnuCash 3.9 may have a problem. I am still tracking down
exactly what happened in my case. I do have a future reconciliation date on
some transactions that had previously been imported in V 3.8. A preliminary
look at the data file after it was first opened with 3.9 seems to indicate
that v3.9 itself introduced those spurious reconciliation dates. At this
stage it is not clear how these future reconciliation dates have been added.
I reverted to v3.8 (after attempting to reconcile in 3.9 and getting a weird
starting balance not in agreement with the previously reconciled closing
balance) and  I was able to get the correct starting balance and complete
the reconciliation to the end of the next statement (I didn't actually apply
it) but the difference was 0 and the reconciled balance agreed with the
closing balance of the statement.  

I am in the process of chasing this up in the XML datafiles and my backups
(last 30 days) which go back to before I changed from 3.8 to 3.9 to try and
determine exactly when and how the spurious future reconciliation dates came
about. It may have been a mistyping on my part while reconciling what is the
target account of the splits from the account I am currently trying to
reconcile. Why should the reconciliation dates of the splits that are to an
account other than the one I am currently I am reconciling  affect the
process of reconciliation? From an accounting perspective my view is that it
should not. Reconciliation of accounts should only be dependent upon the
splits to the account being reconciled and the exrternal statement that it
is being reconciled against, not the data associated with any other account. 

A more important question is how these spurious future reconciliation dates
arise in the first place. Most likely as a result of mistyping the date
during entry.

*At this I would suggest reversing these changes to the starting balance
calculation if possible in 3.10, abandoning 3.9 and reverting to 3.8 until
3.10 can be released. I think a more thorough examination of the cause of
the problem it is trying to address and whether checks on the entered
statement date and issuing a warning for the user to decide is not a better
approach. Derek's is possibly the only user case where one might want to
reconcile in advance

1. I fail to see why there is any necessity to restrict the statement date
in any way. OK warn the user that their statement date is in the future with
a popup, but if that is what they want to do why stop them.


2. I don't agree with imposing any random repair process. I think we need to
identify firstly how and why this is ocurring and particularly why
historical dates that are not associated with transactions in recent
reconciliations are having their reconciliation dates altered (see below) by
a relatively recent reconciliation processes. The reconciliation process
should not be altering records of past reconciliations. Once that is
identified and fixed then consider a repair process. *

The problem is I have now found spurious 2020-12-31 reconciliation dates
applied to transactions which were recorded and reconciled originally at the
time 2015 -2017 in the Paypal account I have been trying to reconcile for
2019-2020 and these are also present in my back up files as at 22/03/2020
which were created when  I was still using v3.8 ( I only keep 30 days of
backups) so I can't go back further. Only the reconciliation dates on the
Paypal account have been changed and reconciliation dates on other splits in
the same transactions are still set at dates in the 2015-2017 range which
indicates that it is a reconciliation process applied to the Paypal account
which is causing the problem. AFAIK at this stage the spurious 31-12-2020
reconciliation date is only occurring in my Paypal account (Liability) and
not any other accounts.

I have established that I reconciled thePayPal account on 03/04/2020 in v3.8
(v 3.9 was installed on 06/04/2020 at 17:46:55AEST and I mark statements
which have been reconciled by appending "_R" to the file name so the file
modification times when I did the reconciliation) against a statement to
31/12/2019 which is when I could possibly have entered the 31/12/2020 date
incorrectly if that was the cause.  However the spurious reconciliation date
of 31-12-2020 is present in transactions to the PayPal account in a backup
file created 22/03/2020 so it is hard to explain as a result of a
reconciliation which ocurred on 03/04/2020. The problem with a future
reconciliation date being present was then not created by V3.9 and Chris
Lam's mod only highlighted that it was already present.

David Cousens



-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html