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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
