[GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

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 at 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 <derek at 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 at 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
> >        derek at ihtfp.com             www.ihtfp.com
> >        Computer and Internet Security Consultant
> >
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>