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