Bug 797640 - The Reconciliation Window starting balance calculator needs to ignore splits after statement date

[christopherlam]

adds a couple helper functions in account.cpp and gnc-ui-balances.c

[jralls]

In addition to the inline comments, you need to somehow compute the closing reconciled balance for the statement you're examining and to provide for displaying the splits that were reconciled in the statement being checked so that the reconcile window makes sense. The reconcile window currently displays only the splits that are unreconciled.

[christopherlam]

In addition to the inline comments, you need to somehow compute the closing reconciled balance for the statement you're examining and to provide for displaying the splits that were reconciled in the statement being checked so that the reconcile window makes sense. The reconcile window currently displays only the splits that are unreconciled.

I haven't addressed the above request at all. I think this reconciliation work is still incomplete:

• we can now reconcile past statements
• however the reconcile information dialog pasted as follows will attempt to calculate a reasonable ending balance whenever the statement date is modified, as long as the ending balance hasn't been modified by the user. I think this calculation is still flawed. If I set statement date to 31/01/20, the ending-balance resets to $72.00
• ditto the starting balance calculator ($126.00) in the reconcile information dialog.
  

[jralls]

That's not the ending balance I was thinking of. It defaults to the last regular balance on the day given and that's probably as close to right as it can be because there's no way for GnuCash to know which transactions are reflected in the bank's statement. The user is expected to replace that default with the amount on the statement.

The ending balance I meant is the ending reconciled balance used to match the statement balance, and it will be the reconciled balance as of the end of the statement date using the new calculation from this PR.

That leaves the display of the already-reconciled transactions. ISTM the display for an old statement should show both the unreconciled transactions and the transactions previously reconciled on the statement date so that the user can review the whole statement. One might go further and show also the transactions posted before the statement date that were reconciled later with some indication of that.

[fellen]

I am not shure if it is useful in this context, but actions->online actions->get balance and some file formats like MT942 contain a balance.

[christopherlam]

That's not the ending balance I was thinking of. It defaults to the last regular balance on the day given and that's probably as close to right as it can be because there's no way for GnuCash to know which transactions are reflected in the bank's statement. The user is expected to replace that default with the amount on the statement.

I just had a thought that every reconciliation involves a statement_date and ending_balance, and it would be possible to store these amounts somewhere which then act as a soft balance assertion and could be used to sanity-check an account via a custom report. Re-reconciliation can also retrieve these old statement_date+ending_balance pairs.

The ending balance I meant is the ending reconciled balance used to match the statement balance, and it will be the reconciled balance as of the end of the statement date using the new calculation from this PR.

You mean the following Ending Balance which has not been changed at all?

That leaves the display of the already-reconciled transactions. ISTM the display for an old statement should show both the unreconciled transactions and the transactions previously reconciled on the statement date so that the user can review the whole statement. One might go further and show also the transactions posted before the statement date that were reconciled later with some indication of that.

This will be rather difficult in the Reconcile Window I think, and may be best left to an augmented Reconciliation Report.

[jralls]

I guess you could store the balances in the Account's KVP.

No, I mean Reconciled Balance. Ending Balance is what the user entered in the Reconcile Info dialog.

[christopherlam]

Here's some further changes which fixes the suggested ending_balance in the reconcile info dialog. I think this is useful but would prefer confirmation.

modified   gnucash/gnome/window-reconcile.c
@@ -388,8 +388,8 @@ gnc_start_recn_date_changed (GtkWidget *widget, startRecnWindowData *data)
         return;
     new_date = gnc_date_edit_get_date_end (gde);
     /* get the balance for the account as of the new date */
-    new_balance = gnc_ui_account_get_balance_as_of_date (data->account, new_date,
-                  data->include_children);
+    new_balance = gnc_ui_account_get_reconciled_balance_as_of_date
+        (data->account, new_date, data->include_children);
     /* update the amount edit with the amount */
     gnc_amount_edit_set_amount (GNC_AMOUNT_EDIT (data->end_value),
                                 new_balance);

[jralls]

No, that would be wrong: Consider the normal situation where you're reconciling a just-arrived statement. This would make the proposed ending balance equal to the starting balance.

The best default GnuCash can use is the cleared balance on the statement date if it's different from the starting balance, otherwise it should use the plain balance. That's the current behavior.

[christopherlam]

I tried as follows but doesn't seem to produce good ending_balances. May be best wait for #667 to be completed then. https://github.com/Gnucash/gnucash/compare/maint...christopherlam:maint-reconcile-ending-balance?expand=1

[jralls]

Not surprising since you didn't test for inequality to the reconciled balance and fall back to balance-as-of-date. Did you create a test account with cleared but not reconciled splits to test with?