How difficult would it be to craft a report that exposes these *possibly* errant dates? I’m thinking something that compares closing date to transaction dates in that reconciliation. If they don’t match, they get flagged to end up on a report. It is certainly possible to have out of period transactions, but this would be a starting point. Of course, I don’t know if the data file even contains this info. Is the closing date and/or reconcile date stored with a transaction’s reconciled flag?
Or maybe this should be a check in the code on first run to alert the user to possibly errant reconciliations with an opportunity to correct them. The report might be better though because the amount of transactions and reconciliations might be large and the user might need to tackle them over a longer time frame than a single session after upgrading. Regards, Adrien > On Apr 2, 2020 w14d93, at 12:10 AM, Christopher Lam > <christopher....@gmail.com> wrote: > > Thank you for helping troubleshoot this issue. > > The dilemma is whether to keep this change which exposes invalid > reconciliation statement dates, or revert to previous behaviour. The only > UI available to fix these dates is to unreconcile the old splits and > rereconcile old statements (or use latest statement). > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
