[GNC] Handling transaction edits after reconciliation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[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
_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Handling transaction edits after reconciliation

Adrien Monteleone-2

> On Mar 10, 2019, at 8:20 PM, James Blair <[hidden email]> 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
_______________________________________________
gnucash-user mailing list
[hidden email]
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.