[GNC] Handling transaction edits after reconciliation

[James Blair]

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