[GNC] [GNC-dev] About 3.9 and reconciliation balances

[Adrien Monteleone]

I concur with this part. Rather than change the calculation, do a check for an errant ending date. Introduce some means to do a check on the whole file as a ‘first run’ event on upgrading. Provide a means to edit the errant data directly rather than revert and re-reconcile. Reconciliation data should somehow be visible to the user if at least in the form of a report.

This may or may not dovetail with being able to correct a reconciliation that was blown up as a result of editing spelling in a Description where the transaction gets its flag changed. (I understand that is something different, but the correction mechanism might be able apply to both cases)

Regards,
Adrien

> On Apr 7, 2020 w15d98, at 5:20 AM, D. via gnucash-devel <gnucash-devel at gnucash.org> wrote:
> 
> 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.