[GNC-dev] About 3.9 and reconciliation balances

[D.]

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.lck at gmail.com>
Sent: Tue Apr 07 13:00:55 GMT+05:30 2020
To: gnucash-devel <gnucash-devel at 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 at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel