The "purpose" for the "fix" was to allow future features:
1. allow manual reconciliation of an account, using past reconciled_date and relevant past ending_balance. If my "fix" were applied, it would serve *me* very well: (a) If an account, properly reconciled, had an errant split hiding somewhere caused by fat-finger, I could reconcile from any past bank statement, verify the balance is correct (or not) and narrow down to the exact period that contains the errant split. (b) This was also useful to fix cases where a past split was unreconciled and needed to be rereconciled -- you could reconcile latest statement and change the field 'n' to 'y' but its reconciled date would *not* be accurate anymore because it'd be the latest statement; I meant to reset the split reconciled_date to be the statement_date. 2. a natural extension of allowing past reconciliation is to store the list of statement_date and ending_balance somewhere in the account metadata and retrieve the list in reconcile_window. Hence https://github.com/Gnucash/gnucash/pull/667 is born. https://user-images.githubusercontent.com/1975870/77246245-5a1e2d80-6c1d-11ea-8fc3-b2ec34fdb5f9.png is possible. In my testing, rereconciling past statements is nicely upgraded. 3. a benefit of maintaining old reconciled_data is that we can now compare an account's reconciled balances at periodic dates against the stored list, and loudly report if a balance discrepancy is found. See https://user-images.githubusercontent.com/1975870/78035104-2c8d5e80-7358-11ea-95bc-feba7f9f2bba.png -- note the first two lines show reconciliation and account balances match; the third section show unequal balances and show the relevant splits which contain an extra one. So, (1) and (2) are not possible -- rereconciling past statement cannot currently take place (unless code sets/queries a book property "use strict reconciled dates"), but I believe (3) is still possible. It won't happen until 4.x though. On Fri, 10 Apr 2020 at 18:51, Dale Phurrough via gnucash-devel < gnucash-devel@gnucash.org> wrote: > Yes JR and DA 😄 > Nothing bad or sinister, rather a future opportunity to virtually > whiteboard the concepts and events surrounding "reconciliation", then > reviewing what gnucash currently does to see the gaps. > > It's comforting to see that it works for so many scenarios, and the > discussion on this was hardy for change/regression. > With it reverting to 3.8 behavior, I see all this as a healthy outcome with > a opportunity for the future. I'll gladly participate in it as I'm a > regular qif, ofx, manual, multiple currencies reconciler. > > On Fri, Apr 10, 2020, 6:43 PM Derek Atkins <de...@ihtfp.com> wrote: > > > Dale, > > > > On Fri, April 10, 2020 12:37 pm, John Ralls wrote: > > > > > > > > >> On Apr 10, 2020, at 8:22 AM, Dale Phurrough via gnucash-devel > > >> <gnucash-devel@gnucash.org> wrote: > > >> > > >> This feels like a separation of accounting logic -- separate from > > >> storage > > >> field -- has broken down. From what you wrote, it seems each of these > > >> sources have direct access to core fields without any > > >> accounting/business > > >> logic to control the transaction of reconciliation nor to validate the > > >> input into that reconciliation. > > > > > > Unfortunately there is very little such separation anywhere in GnuCash. > > > > Even moreso, in many cases (e.g. Import) the data just isn't there! QIF > > has a reconcile flag but does not contain a reconcile date field. So if > > you're importing reconciled data, what should you use for the reconciled > > date? Over time, different developers working in different parts of the > > code made slightly different decisions, because at the time the actual > > date didn't matter because nothing used it. > > > > -derek > > > > -- > > Derek Atkins 617-623-3745 > > de...@ihtfp.com www.ihtfp.com > > Computer and Internet Security Consultant > > > > > _______________________________________________ > 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
