Christopher, I have to admit to some trepidation at having something as significant to my books as reconciliation suddenly changed based on data elements that aren't visible in the GUI. Are you sure the solution is better than the problem?
I'm also concerned at the fact that (as with some other reports you've changed in the past) you are changing GnuCash behaviors without considering their effects on end users, and then waiting for the outcry from users to enact fixes. That is poor planning on your part, and has significant effect on the user base. Perhaps you should revert this change for the time being, until such time as you figure out a solution that works for the user base. For example, give the user an interface that allows them to see and fix the kinds of errors you've already identified. As for your proposed safeguards, option 2 should better be implemented by giving the user a listing of spurious reconciled txns, and giving them some interface to set a proper date (or a better one) on a group or individual basis, rather than arbitrarily creating a date that will cause the user to question the quality of their data sometime down the road. David T. -------- Original Message -------- From: Christopher Lam <christopher....@gmail.com> Sent: Tue Apr 07 13:00:55 GMT+05:30 2020 To: gnucash-devel <gnucash-devel@gnucash.org> Subject: [GNC-dev] About 3.9 and reconciliation balances Release 3.9 comes with a new method for calculating reconciliation starting balances. Previously, the account reconciled balance was considered the starting balance. This includes any splits previously reconciled with an invalid (e.g. future) reconciliation statement date. From 3.9 onwards, the starting balance is calculated by adding all account splits whose *previous *reconciled date the *current* reconciliation date. This means any past reconciliation with an invalid (ie future) reconciled date would be ignored. The benefit is to allow re-reconciliation of a past statement. So, anyone with difficulties reconciling an account with 3.9 onwards should check the account Reconciliation Report, Start Date = today, End Date = 31/12/9999 to seek these splits. To fix it manually, you can unreconcile them and re-reconcile with any past date or today. Or modify the XML/SQL to fix these dates. To prevent future issues there are several safeguards being planned for 3.10: 1. any reconciliation must have a statement date of TODAY + 1MONTH. This allows some leeway for users who wish to reconcile in advance, yet disallows reconciliation too far ahead. 2. a datafile with splits with reconciled_date in the future *may *be repaired; e.g. if reconciled_date > 1 month from today, then it is evidently an error and can be changed to an arbitrary old date eg 1/1/1970. This will allow them to be counted when calculating modern reconciled balances. I think 1 is acceptable. Any particular votes for 2? _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
