[GNC-dev] About 3.9 and reconciliation balances

[Dale Phurrough]

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
>
>