[GNC] Handling transaction edits after reconciliation

[Adrien Monteleone]

> On Mar 10, 2019, at 8:20 PM, James Blair <atx.gnucash.bugzilla at gmail.com> wrote:
> 
> 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

To post to an older thread than you have access to in your inbox, (or one you’ve since deleted) simply follow this procedure:

From the archive page (like the two links you provided above) of the message you want to reply to, click the original sender’s linked name.

This will open a new mail message in your client with the subject pre-populated.

The only other thing you need to do is either replace the original sender’s e-mail address (now a recipient ’To:’) with the list address, or add the list address as well.

Note, this only works with desktop clients. (perhaps mobile, not sure, but I don’t see why not) It doesn’t work with web clients unless some magic has been performed that I’m not aware of. (*maybe* if your OS launches your web client, logs you in and starts a new message, *maybe* but I doubt this is even possible)

> 
> 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?

If you reconcile on a generally regular date after receiving your statement, you’d notice an older transaction that should be reconciled but isn’t.

> 
> 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?

You could also run and save an account report showing all reconciled transactions post-reconcilation for that period. To answer your question, look at the report. If it isn’t there, then you never reconciled it. If it is, then you edited it.

> Is it a duplicate transaction that should be deleted?

A simple review of transactions for that date would answer this. If you think you edited the date, then filtering or searching the account for the Description (or other info) would show 2 or more duplicates.
> 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?

Filtering the register view and the Find function can help greatly here. Also, see below about marking it ‘cleared’ after editing.

When editing transactions with a date before the last time you reconciled, make it a habit to glance at the reconciled flag first so you have a heads up it might change. (of course, you should always get a warning, and I think that is part of the bug that needs to be addressed. I also think too many fields trigger the flag being unset.)

You can also create a workflow to only reconcile on the 1st/last of the month, regardless of when you get your statement. (you can still mark off transactions as ‘cleared’ when you get the statement if that helps) That way you have an instant clue that more than likely you might be editing a reconciled transaction.

> 
> 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.

You could also just mark the transaction cleared ‘c’ as part of the edit (maybe you have to do it after it clears the ‘y’ flag) which will have it checked off for you next time you reconcile. ‘c’ means you already know it has been checked and is correct, but simply hasn’t been part of a reconciliation process yet.

Regards,
Adrien