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 > <[email protected]> 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. _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
