Hi. I do have feedback on the 3.10 change suggestions. Meanwhile, I'll not comment on the feature change "3.9 comes with a new method for calculating reconciliation starting balances". I defer to others on this list for that.
1. This time period of one month is arbitrary and my experience suggests this is a symptom of a hack, incomplete solution, or partial workaround. Both (a) allowing future/advance reconciliation -and- (b) disallowing something "too far ahead" is again arbitrary and is forcing an arbitrary accounting policy rather than conservative double-book rules and math. Features with rules which are defined by the computer clock are troublesome. It makes sense when one needs to transfer money via an online API. It doesn't make sense when one is doing core accounting tasks. Also this seems (in my shallow understanding of the 3.9 change) to not work with that 3.9 change. How could someone future reconcile if future-date splits wouldn't be valid with respect to the future-target-reconcile balance? This suggests a cascade of more workarounds. 2. I highly discourage altering any data without explicit disclosure and acceptance of each change occurrence. This is not in alignment with the ideas of data integrity, data persistence, trust and disclosure, etc. Also a similar arbitrary accounting policy with the suggested date>1month logic and 1/1/1970. --Dale On Tue, Apr 7, 2020 at 9:32 AM Christopher Lam <christopher....@gmail.com> wrote: > 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