Bug 241855 - Reconciliation wizard fails to calculate correct difference
Summary: Reconciliation wizard fails to calculate correct difference
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-15 22:55 UTC by John Hudson
Modified: 2010-09-27 22:35 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Hudson 2010-06-15 22:55:05 UTC
Version:           unspecified (using KDE 4.3.5) 
OS:                Linux

After entering a Starting value of 17358.02 and and Ending value of 17475.39 in the wizard, the screen showed:

Statement 17,475.39 Cleared 0.00 Difference -17,475.39

whereas the true difference is 117.37.

Ignoring this, I proceeded to reconcile but the final figure for the difference was way out rather than 0.00 as it should have been.

Reproducible: Always

Steps to Reproduce:
Select Reconcile from icon or drop down menu.

Enter statement date, starting value and ending value; proceed to Finish.

Actual Results:  
Screen shows Ending value with difference equal to 0 minus Ending value.

Expected Results:  
Difference equal to difference between Starting and Ending value
Comment 1 Thomas Baumgart 2010-06-16 08:29:42 UTC
http://kmymoney2.sourceforge.net/online-manual/details.reconcile.html contains some information about the reconciliation process. Maybe, we should add an explanation on what the numbers at the bottom of the ledger mean.

The left column (statement) contains the ending value of the period as entered by the user in the reconciliation wizard.
The centered column (cleared) contains the sum of all transactions in that account that are marked cleared or reconciled (that is all transactions up to and including the entered statement date).

The right column (difference) shows the difference between the centered and the left column (cleared - ending balance).

So in the end, the centered column must match the left column and then the difference is zero.

In case the values seem to be off, it is a clear indication to some problems in history of your transactions (which means prior to the start date of the current reconciliation period). Are they all marked reconciled? If not, please do.

So as far as I can see, the application works as designed. Maybe, we need to enhance the documentation at this point.
Comment 2 John Hudson 2010-06-16 10:28:48 UTC
The problem was that I had imported the accounts from a different package and had not marked the imported transactions as reconciled. So though the Starting value which I entered was the correct balance on the date from which new entries had been made into KMyMoney, the unreconciled transactions from before that balance were being included in the reconciliation. 

In other words, the wizard was ignoring the Starting value given in the dialogue and using the value of 0.00 when the account had been opened. Once I had marked the imported transactions as reconciled, it worked normally.
Comment 3 Thomas Baumgart 2010-06-16 10:37:56 UTC
Would it make sense to issue a warning message if we find unreconciled transactions before the start date of the statement and that those should be marked reconciled before?
Comment 4 John Hudson 2010-06-16 23:05:59 UTC
It looks as if the wizard ignores any Starting value entered and calculates its own. One possibility would be remove the option for the user to enter a value and add an explanation of what to do if the value is not what the user expects; another would be to permit the user to enter a value and then, as with splits, if this value was different from the one calculated by the wizard, to put up a warning message with options.

I routinely have unreconciled transactions before the last reconciliation date; so it would be important not to confuse users into thinking that they need to do anything about these.

I don't know if, after importing from GnuCash or other programs, transactions are automatically set to reconciled; in my case I am importing by hand from a program that has been unsuitable for the user to give them a fresh start.

So my guess is that the innocent explanation for the Starting value being different from what the user might expect is most likely to be connected with importing. The user would need to be aware that some explanations might not be innocent and would require user input to correct.

How much of that went into a warning and how much into the documentation I don't know.
Comment 5 John Hudson 2010-06-16 23:06:12 UTC
It looks as if the wizard ignores any Starting value entered and calculates its own. One possibility would be remove the option for the user to enter a value and add an explanation of what to do if the value is not what the user expects; another would be to permit the user to enter a value and then, as with splits, if this value was different from the one calculated by the wizard, to put up a warning message with options.

I routinely have unreconciled transactions before the last reconciliation date; so it would be important not to confuse users into thinking that they need to do anything about these.

I don't know if, after importing from GnuCash or other programs, transactions are automatically set to reconciled; in my case I am importing by hand from a program that has been unsuitable for the user to give them a fresh start.

So my guess is that the innocent explanation for the Starting value being different from what the user might expect is most likely to be connected with importing. The user would need to be aware that some explanations might not be innocent and would require user input to correct.

How much of that went into a warning and how much into the documentation I don't know.
Comment 6 Alvaro Soliverez 2010-06-18 04:05:47 UTC
The way I see it, the starting balance and date has no use in this case. Perhaps it makes sense for online accounts, but I'm not so sure about manual reconciliation.
What it would be good to have is the date of the last reconciled transaction, the amount of cleared and not reconciled transaction, and the date of the earliest not reconciled transaction.
Comment 7 Alvaro Soliverez 2010-07-30 02:25:10 UTC
The reconciliation, on its main page, has 3 fields:
- statement date
- starting balance
- statement balance

The starting balance might cause confusion, because its use is not clear. Actually, it is only used for the automatic reconciliation and to emit the accountReconciled signal later used by some plugins.

To me, it is not clear why or what the user should enter into that field.
Is that the balance of the last reconciled date? 
Is it the opening balance if the account has never been reconciled?

If it is the starting balance of the statement, then why not enter the date for that starting balance, and also limit the reconciliation to those dates?

Possible solutions:
1) make the starting balance a calculated field. Use the balance of the first not reconciled transaction on that account.

2) add the starting date of the statement, and limit the reconciliation to the dates within the statement. Use the first not reconciled transaction to suggest starting date and balance, or the last reconciled data, if any.
Comment 8 Jack 2010-07-30 02:35:29 UTC
Your first solution makes sense, but would need to have a clear explanation to the user where that value came from.

The second solution has a problem.  My bank statements use the clearing or post date of checks, but I make the transaction date the date I wrote the check, which often is before the start of the statement when it cleared.

This is the reason you might have non-cleared transactions prior to the last successful reconciliation, so in fact, you might want to display the date and balance of the last reconciliation as well as the date and balance of the oldest non-reconciled transaction, but use the latter for the calculations, recognizing that there might already be reconciled transactions in that interval.
Comment 9 Alvaro Soliverez 2010-07-31 14:21:14 UTC
Is there a case where option 1) would not apply?
ie. where the user might want to enter an arbitrary balance? I don't see the reason to not have this field calculated. I think it leads to more confusion.
Comment 10 Russ Fineman 2010-08-10 21:40:59 UTC
Just a comment. I have to agree with Jack (Comment#8). Many months I have checks that have not cleared the bank yet Some even two or three months old). If you ignore unreconciled checks prior to the statement date it will cause great problems.
Comment 11 Alvaro Soliverez 2010-08-28 02:12:56 UTC
Ok. So I would go with option 1).
For that, I would take the last reconciled balance, or the opening balance if the account has never been reconciled before.
Comment 12 Alvaro Soliverez 2010-09-27 22:35:13 UTC
SVN commit 1180385 by asoliverez:

Set the start balance of the reconciliation wizard to read-only, and add a label with the date of the oldest not reconciled transaction.

BUG:241855

 M  +0 -1      checkingstatementinfowizardpage.cpp  
 M  +10 -3     checkingstatementinfowizardpagedecl.ui  
 M  +14 -1     kendingbalancedlg.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1180385