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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel