At Geert's request, I am adding my voice to the list of mailing list users who object to changes that automatically mark a transaction unreconciled when certain fields are edited. I regret that I wasn't subscribed to the list about two months ago, so I am unable to reply easily to archived threads. For context, here are some links:
Bug I reported when I first recognized the unreconciling behavior in GnuCash 3.4: https://bugs.gnucash.org/show_bug.cgi?id=797084 Original post in the most relevant gnucash-users discussion: https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081797.html Most recent post in that discussion: https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081942.html Aside from arguments previously presented in that thread and in my bug report about which fields should become protected during reconciliation, I've been thinking about a new concern. How do I tell the difference between transactions (or maybe "splits" is more accurate, I'm not sure) that have not yet cleared and ones that were edited after a previous reconciliation? Say I make a payment to John on January 10. I reconcile this account on January 15. My February 15 bank statement arrives and I start my reconciliation process. My payment to John is not marked reconciled. Did I reconcile that transaction on January 15 and then edit an unprotected field? Is it a duplicate transaction that should be deleted? Is John holding my check without depositing it? To tell the difference between these states, I think I have to examine previous account statements back to my recorded payment date (to distinguish edited from never deposited) and all transactions back to that date (to rule out a duplicate)! This feels to me like an extremely high price to pay for editing transactions that have already been reconciled. Is there a simpler way to resolve this ambiguity that I'm not seeing? One workflow I have seen proposed is to re-reconcile immediately after editing transactions. The user opens up another window, finds the transaction (probably near the top), clicks the box to reconcile it, and clicks finish. But how is that any different than leaving the transaction reconciled? It takes more clicks (does that count as security?) and requires me to hold information in my brain longer about which transaction(s) I just edited. Another proposal might suggest that I would remember editing the transaction, so this dilemma is theoretical rather than practical. I disagree; if I could remember all of the transaction changes I'd made in the last month, I probably wouldn't be relying on a computer in the first place. A workaround I plan to experiment with is to edit the description manually for transactions with post-reconciliation edits, adding a short word or symbol indicating it can be automatically reconciled next time without matching a bank statement. For example, a payment to "Universal Exports" might become "+Universal Exports" or "M*Universal Exports" (M for "modified"). I will place it at the beginning of the description so it is easier to see when scanning the list of transactions in the reconciliation window. James _______________________________________________ gnucash-user mailing list [email protected] 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.
