[GNC-dev] About 3.9 and reconciliation balances

[Dale Phurrough]

Wow...this mix-match of reconcile date behaviors are good to log somewhere
as an design/architecture aberration/bug. Good for discussion on...
1. what *does* the concept of "reconciliation date" mean?
2. does that meaning change with the source of reconciliation/truth (qif,
quicken, AQBanking, manual, etc.). If so, are multiple fields needed?
3. what are the rules and validation for "reconciliation date" before it is
stored into the field?
4. etc.

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.

I agree. Let it stay in 3.8 style so a broader conversation can occur given
all the good new info that have been surfaced in this discussion. 👍

--D

On Fri, Apr 10, 2020 at 4:36 PM Christopher Lam <christopher.lck at gmail.com>
wrote:

> Some further findings. I don't think the "fix" needs to come back.
>
> The reconciled_date field is not well defined in code
> - during manual reconciliation (which I use heavily) it sets
> reconciled_date to statement_date.
> - during QIF import from Quicken, it can also set reconcile_status to
> mirror Quicken reconcile status, but the reconciled_date is never set at
> all, and is interpreted as 01/01/70. These splits would be counted
> correctly if my "fix" were reinstated.
> - during QIF imports from banks (I use occasionally) the importer doesn't
> typically set splits as reconciled but 'c'leared instead
> - during OFX import from bank (I use this heavily) splits are set
> 'c'leared.
> - during AQBanking import splits' seem to be reconciled to TODAY.
>
> Conclusion: I think a future storage for *reconciled_date *and
> *ending_balance* is still possible if it is populated when completing
> successful manual reconciliation, and this does not necessarily need the
> "fix". It would simply serve as a data integrity report verifying account
> reconciled balances are still matching stored balances.
>
> On Thu, 9 Apr 2020 at 23:09, David Cousens <davidcousens at bigpond.com>
> wrote:
>
> > Christopher
> >
> > My remaining concern is that fixing any incorrect reconciliation dates is
> > at
> > this stage a manual procedure requiring the editing of the XML file (SQL
> > database users?). In addition it requires sufficient knowledge of the XML
> > file structure to be able to correctly identify which accounts are
> affected
> > by the errors and to identify what the correct date should have been.
> While
> > this is not as much of a concern for users using GnuCash for their
> personal
> > finances, those using it for business uses may have external requirements
> > imposed on them which may for example require verification of
> > reconciliations if they are being audited.
> >
> > If an auditor examines records which have reconciliation dates that are
> not
> > consistent with the transaction dates it would at the least raise a flag
> > with them. This is an unlikely event but if detected is likely to result
> in
> > considerable expenditure for such a user.
> >
> > I was in the fortunate position of having enough knowledge of how GnuCash
> > works, the datafile structure and enough accounting knowledge and also
> > having the records of exactly when I did the reconciliations to the
> account
> > which allowed me to determine that there had only been one occurrence of
> > entering a statement end date incorrectly and that only the splits to one
> > specific file had been affected. My situation could have been far more
> > complicated. Some users may have records going back much further than
> 2016
> > in a single file. I was fortunate in that after I retired I started a new
> > simplified file for my personal records for my wife and myself.
> >
> > The average user, and particularly business users who will primarily be
> > focussed on their business, is unlikely to be able to fix the XML file
> and
> > many would not feel confident about doing it and the risk of them
> damaging
> > their data file irrepairably is high (although you would clearly be
> foolish
> > to do this without creating one or more backups first).
> >
> > It is easy to say correct the reconciliation dates and rereconcile but I
> > feel it will be necessary to provide users with a means of doing that
> > correction in a consistent fashion (this really requires a knowledge of
> the
> > transaction dates and the dates of entering the transaction and whether
> > other reconciliation dates are used in splits to the particular account
> so
> > that users can select an appropriate reconciliation date which is at
> least
> > consistent with the other dates in their records.
> >
> > I would opt for option 2 at this stage along with popup warnings on
> > detecting the future reconciliation dates and statement end dates ahead
> of
> > the current date, but by default make the feature turned on for new books
> > (these should have no reconciliation dates set - it may be necessary to
> > consider if this affects records imported from a previous book or other
> > program into a new book) and created in the off state when written into
> an
> > existing book which was created without the feature. The warnings could
> > contain a reference to the option i.e. turn it on once you have corrected
> > the advance date. I think this will allow all users to continue to
> function
> > while incorporating the function until such time as we have a robust fix
> > method in place. Even thess will require considerable code changes in a
> > varietyt of areas of the code to get up and running where as the fix
> > procedure will also be a fairly major undertaking.
> >
> > Those who feel they have the necessary skills and knowledge can in the
> > meantime repair their files and switch the feature on if they desire.
> >
> > Unfortunately new options always increase the risk of user confusion but
> > the
> > above approach may minimise this as the user won't see the feature unless
> > they are using a new book or have deliberately chosen to use it after
> > repairing their file.
> >
> > The other obvious thing is to update the documentation with appropriate
> > instructions and in the shorter term put this up on the wiki in the
> > meantime. I don't know if it is legit or desirable to reference a wiki
> page
> > from the documentation or even from within the program (in the warning
> > popups for example) but this may be a temporary way to alert users and
> > point
> > users to a solution until an autofix procedure can be developed.
> >
> > I can start preparing a wiki page outlining the problem and how to do the
> > manual fix to the XML file. I guess SQL users could always save their
> data
> > to XML, do the fix and then reopen the fixed XML file and then resave to
> > the
> > database as a fix while it is fresh in my mind.
> >
> > David  Cousens
> >
> >
> >
> > -----
> > David Cousens
> > --
> > Sent from:
> http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>