[GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

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
>