[GNC-dev] About 3.9 and reconciliation balances

[David Cousens]

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