I would say date is one of those ‘depends’ cases. Changing it to another date within the same period won’t alter the reconciled balance, but changing it to a date outside of the reconciled period of course would. Trying to determine the date range a reconciliation was done for is asking too much most likely. So for simplicity, I’d leave it as is and let it unset the flag. With a warning, the user can decide on the spot to proceed and then re-reconcile right away to keep things tidy if this is an in-period date change.
I know more options means more code and more mental ‘cost’ but should perhaps this list be a set of options? If the user sets the options for their needs, they get a warning and the flag unsets. Otherwise, the default could sanely be to only unset the flag on date and amount. This might also work as a poor substitute for the ’security’ that some users ask for. If they have the option to unset the reconcile flag based on the transaction data they prefer, they might set it for everything. Then they can easily see with a reconcile filter if any transactions before the last reconciliation have been edited. (not perfect or ideal as it won’t prevent the change or tell you who made it) Just a thought. I certainly am not advocating to create more work. Regards, Adrien > On Jan 11, 2019, at 3:37 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> > wrote: > > Hi all, > > Thanks for the feedback, though I preferred to have received it while we were > actually working in that area :( > > So really the only elements to reconcile on are transaction date and amount ? > > Geert > > Op vrijdag 11 januari 2019 03:36:15 CET schreef David Cousens: >> Geert, >> >> My opinion is much the same as Adriens' . The critical information you are >> verifying against a statement is: >> >> the timing (date and/or time) and >> amount of the split to the account being reconciled. >> >> Where data has been manually eneterd into GnuCash, the date may not be the >> same necessarily as a statement as they will record the date and/or time >> relevant to the handling of the transaction in their hands which may be >> different from your own - can be importnat for contracts for example. >> >> I also feel that changing the amount in splits other than the split to the >> reconciled account should not trigger unreconciliation of a reconciled split >> ( which is the crrent position). >> >> Any other information, while it may assist with identifying reconciliation >> (e.g description memo etc), it is not the information which is being >> reconciled itself. >> >> In addition the critical information that defines that transaction's >> identity, i.e. internal GnuCash transaction ID needs to be protected. >> >> My bank doesn't provide in a statement their transaction ID's, or >> transaction time and any description provided is from their perspective not >> mine. My statement is pretty minimal: >> >> Date Descriotion Debit Credit Balance >> Balance State (Db/Cr) >> >> It is interesting that the OFX files I import from my bank often contain >> much more information than the statements. They however are created on >> demand whereas my statement often comes out a few weeks weeks after the end >> of the relevant period and does not contain any pending events etc and any >> clearances have been resolved. With electronic clrearance times now being >> very short, these sort of discrepancies in accounts are now generally fairly >> infrequent now >> >> While accounts with bank statements (asset, liabilities) will be the most >> commonly reconciled accounts, they are not necessarily the only ones. In the >> days when I ran a business, I could request and received statements form >> vendors and supplied them to customers to verify that we agreed on what was >> owed to them or by them. If you track income or expense by customer or >> vendor then you may also find yourself reconciling these, especially if >> there is a dispute. >> >> >> David Couens >> >> >> >> ----- >> David Cousens >> -- >> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html >> _______________________________________________ >> gnucash-user mailing list >> gnucash-user@gnucash.org >> To update your subscription preferences or to unsubscribe: >> https://lists.gnucash.org/mailman/listinfo/gnucash-user >> If you are using Nabble or Gmane, please see >> https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- >> Please remember to CC this list on all your replies. >> You can do this by using Reply-To-List or Reply-All. > > > > > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
