GNOME Bugzilla – Bug 406937
reconciliation should not silently drop checkmarks
Last modified: 2018-06-29 21:26:33 UTC
Please describe the problem: In the reconciliation interface, when a user checkmarks a transaction but the transaction is for a date newer than the statement date, then the user clicks postpone and comes back later, the transaction is silently unchecked. This is a real problem for reconciliations for bank accounts that consist of multiple pages worth of transactions, particularly for transactions in which a single line on the bank statement corresponds to multiple transactions within gnucash, because it's often a real mystery as to what gnucash "backed out". Steps to reproduce: 1. enter in some transactions for a bank account in gnucash 2. put one or more of them beyond the reconciliation statement date 3. try checking some of the transactions plus the one beyond the statement date 4. click to postpone 5. go back in to reconcile Actual results: the transaction(s) beyond statement date will be silently unchecked Expected results: if gnucash intends to uncheck some of the transactions, it should give a warning informing the user what it's doing Does this happen every time? yes Other information:
I think this behaviour is indeed intended, except that "Postpone" is the wrong word to leave the Reconcile Dialog. I think we rather intended to have "Cancel" there, which means you will also loose all changes you did in the dialog (like checking/unchecking transactions). As a workaround, you can mark the transactions directly in the register as "cleared", and only after you've gone through your written statement once, open the Reconcile Dialog as a second step. Alternatively, we could ask for an enhancement request that is a real "Postpone" feature, i.e. closing the Reconcile Dialog without loosing the work done so far.
"Pospone" leaves the reconsiliation dialog, and any items that are checked in the dialog are marked as cleared in the register. "Cancel" leaves the reconciliation dialog and discards any changes made. These buttons work correctly. The problem is when the reconciliation dialog is first opened. It does not set the checked state of items based upon their cleared state in the register. It simply (incorrectly) leaves all items unchecked.
Anytime the reconciliation dialog opens, (regardless of the existence of postponing in the past) all cleared splits before or on the statement date are checked. David is correct in noting that splits marked in the reconcile window are set to clear on postpone. Checking off *all* cleared splits when opening the reconcile window would fix the problem Jamie has, the user perception that work has been lost, but there's a downside. Splits that the user marked clear from a register will get checked when started/resuming reconciliation as well. Users are not going to want splits *after* the statement date that they've intentionally marked cleared to be checked off in the reconcile window, as they'll be forced to uncheck them. But they also don't want things they check off in the reconcile window to appear to disappear when they come back from a postpone. The problem is here is that users are attempting to check off items outside the statement date. This kind of mistake could take place for two reasons: * The transaction date is wrong, (it really should be before the statement date), and the user fails to notice it is wrong * The transaction date is right, the user confuses it with a different transaction from the period being reconciled, and checks it in error One potential solution is to prevent the user from checking off a split past the statement date in the first place. I wouldn't achieve this by hiding the split; doing so will prevent the reconciliation process from fixing correct transactions with wrong dates. Instead, show the split, don't let the user check it, and perhaps even communicate why they can't check it. I could imagine someone feeling that preventing these splits from being checked would be taking away power from users. GnuCash isn't known for trying to herd its users into certain accounting practices. But, preventing these transactions from being checked wouldn't be a terrible power loss for users uninterested in the importance of dates; such users could simply enter a later statement date when starting reconciliation and get the same result. If this proposed fix were really contentious, it could always be made optional.
I believe the problem in comment #1 is that the user didn't set the "Check cleared transctions" in the register pane of the preferences window. jamie, can you test this hypothesis? I believe hiding splits is wrong, precisely because they might have been entered with the wrong transaction date. I'm not convinced that preventing users from checking transactions after the cutoff date wouldn't cause more problems that it would fix.
(In reply to comment #4) > I believe the problem in comment #1 is that the user didn't set the "Check > cleared transctions" in the register pane of the preferences window. jamie, > can you test this hypothesis? It's true : if "check cleared transactions" is unchecked then ANY postpone means that going back to reconcile again doesn't have anything checked (and thus acts the same way cancel would) > > I believe hiding splits is wrong, precisely because they might have been > entered with the wrong transaction date. I'm not convinced that preventing > users from checking transactions after the cutoff date wouldn't cause more > problems that it would fix. > I agree : particularly if the transaction is unique enough to obviously be the correct one (eg cheque number 2366, for vendor Bob's Tools, for amount $22.14. There aren't going to be a lot of duplicate cheque numbers for that vendor for that amount unless the business's policies are really odd). But rather than preventing the user from doing anything, it would be good to either warn them that their checkmark will not show up again if they postpone and maybe ask them if they want to date the transaction such that it WILL show up, or alternately change the reconcile window to show ALL stuff that's cleared but not reconciled.
> It's true : if "check cleared transactions" is unchecked then ANY postpone > means that going back to reconcile again doesn't have anything checked (and > thus acts the same way cancel would) No, it doesn't. All you have to do is to set the "check cleared transactions" preference before you start the reconciliation. You aren't understanding how the software works. Cancel leaves all the transaction reconciliation flags the way they were when you started the reconcile. Postpone updates the transactions reconciliation flags to match the way that are marked in the reconciliation window. You're ascribing a problem to the postpone step that is actually the result of gnucash doing what you asked it to do by not setting the "check cleared transactions" preference.
(In reply to comment #6) > > It's true : if "check cleared transactions" is unchecked then ANY postpone > > means that going back to reconcile again doesn't have anything checked (and > > thus acts the same way cancel would) > > No, it doesn't. All you have to do is to set the "check cleared transactions" > preference before you start the reconciliation. > > You aren't understanding how the software works. Cancel leaves all the David : you asked me to test the hypothesis that the behaviour described by comment #1 was due to "check cleared transactions" being off. I tested your hypothesis and confirmed that this was true. However, I am not comment #1. Comment #1 is Christian Stimming. I was never getting the behaviour described by comment #1. The behaviour I originally described occurs WITH the check cleared transactions setting ON. If this checkbox is NOT on, then the behaviour is identical to cancel. If it IS on, then things the user checks passed the statement date are silently lost. > transaction reconciliation flags the way they were when you started the > reconcile. Postpone updates the transactions reconciliation flags to match the > way that are marked in the reconciliation window. No. It doesn't. >You're ascribing a problem > to the postpone step that is actually the result of gnucash doing what you > asked it to do by not setting the "check cleared transactions" preference. As I said above, I only turned this preference off when you asked me to test a hypothesis as to why someone else was getting behaviour that did not match what I had originally described.
Created attachment 99550 [details] [review] Adds an option to the Register preferences to disallow checking off transactions past the reconciliation statement date in the reconciliation window. If the option is selected in the preferences then a dialog informs the user when they try to toggle a transaction after the reconciliation date that they cannot do so, and that this can be turned off in the preferences. It also includes the fix to stop transactions past the transaction date being set from 'c' to 'n' in the register if they are not checked off in the reconciliation window (as they are not with auto-check on) when the reconciliation is postponed. Without this fix when the "no-toggle" option is on users either have to postpone and lose data in the register (which transactions after the reconciliation date have 'c'leared) or cancel the reconciliation (losing any changes they made in the reconciliation window).
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=406937. Please update any external references or bookmarks.