Bug 325793 - loan payment calculated using wrong currency when currencies of loan and payment account differ
Summary: loan payment calculated using wrong currency when currencies of loan and paym...
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.6.3
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-08 20:46 UTC by Igor Šuljić
Modified: 2015-03-31 16:18 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.2


Attachments
screenshot of the final step of the Create Loan Account wizard (121.01 KB, image/png)
2013-10-08 20:54 UTC, Igor Šuljić
Details
Home page after creating the Loan Account (380.48 KB, image/png)
2013-10-08 20:57 UTC, Igor Šuljić
Details
Test file that shows this issue. (31.32 KB, text/xml)
2014-07-31 09:26 UTC, Cristian Oneț
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Šuljić 2013-10-08 20:46:41 UTC
As a new user I am trying to import an old loan that is partly already payed off. Initial amount is 8500 €, the contracted interest rate is 10,98% variable, recalculated monthly (though, so far, it didn't change at all, and explanation is beyond my financial competences). The currently unpaid amount is 3208,02 €, with 19 monthly transfers of 184,73 € left. Transfers include interest. The bank is calculating the loan in euro, and actually handling it in local currency, croatian kuna in this case.
So I entered both the loan and the monthly payment amount using euros, but the checking account that is charged with transfers is using the other currency, croatian kuna. That is because the bank is converting the transfer into kunas (using its own exchange rate ;-)) and charging the account accordingly. The wizard correctly calculates the loan, as can be seen from the attached screenshot (loanwiz.png), but in the balances view the transfer is reported as 184,73 kunas, not euros (the other attachment, balances.png) and accordingly deducted from the checking balance. When I try to edit the transfer, there is no option of changing the currency, and if I try to change the transfer amount to some 1407,64 kunas, that is currently 184,73€, the wizard reports error and recalculates the number of payment terms to 2.

Reproducible: Always

Steps to Reproduce:
1. Have a checking account using currency other than euro (croatian kuna, HRK in my case).
2. Create a new loan account with the same institution as the checking account (wizard step 1).
3. Make it in euros with opening date few years ago (10.05.2010 in my case), opening balance of 8500 €, and accept online quoted conversion rate, it is pretty exact in my case (wizard step 2).
4. You are borrowing, the payee is the same institution holding your checking account, you have already made some payments and want to start with this year's payments, so the balance before start of recording is less than the opening balance (3208,02 € in my case). Both, the payment frequency, and the interest compound frequency are monthly. Due date of the first payment recorded is within one month in the future (the last day of the current month in my case). The interest rate is variable, it is changing monthly, and the next change is one month after the first recorded payment, though all this proved to be insubstantial in my case. The bug was exactly reproducible with fixed interest rate. (wizard step 3).
5. The interest rate is calculated when the payment is due, and the rate is high (10,89 in my case, remember, this is wild East, the banks are italian, austrian, german, french, the legislation and corruption local). It is unclear what are the loan amount and number of terms to be entered here, the initial or the remaining ones. Nevertheless, the outcome is the same, so enter the remaining ones, that are suggested (wizard step 4).
6. There are no additional fees. Note the correct periodical payment rate and currency shown. (wizard step 5).
7. Add some category, and make sure it is euro. At this point, even before you enter the institution, when you walk back through the wizard, you'll notice that the loan currency in the step 2 is changed to local currency (kunas), and you have lost the institution in both, step 1 and step 3. That seems to be OK, as you can change back all of these, and come back to the step  6 of the wizard to complete it with always the same, and the only institution you have so far. However, if you already have the category created, and complete this step, then all your previous data are retained, and you can go on.
8. In recapitulation everything is OK, currencies correct. So finish the wizard in step 7.
9. Now take a look at the application's Home page. Your loan is there in the Liabilities and Assets Summary table, right as it should be, but in the next table, Payments, there is your payment scheduled in local currency (kunas), and in the euro amount (now it is 184,73 HRK, not 184,73 € that converts to 1407,64 HRK), therefore not converted. The incorrect amount is then correctly deducted from the assets.
Actual Results:  
Scheduled transfer of monthly loan payment is not converted, but simply relabeled from loan to payment currency.

Expected Results:  
The transfer is supposed to either be converted into local currency, and then deducted from the assets, or reported in correct currency (euro) and then converted during deduction, as is the case with the loan principal and net worth.

May be related to bug 316070.
I will try adding euro subaccount to the main checking account. Depending of the result, the application could prove unusable for me.
Comment 1 Igor Šuljić 2013-10-08 20:54:12 UTC
Created attachment 82728 [details]
screenshot of the final step of the Create Loan Account wizard

The state of the account after finishing the Create Loan Account wizard. Everything is as expected.
Comment 2 Igor Šuljić 2013-10-08 20:57:10 UTC
Created attachment 82729 [details]
Home page after creating the Loan Account

The schedule of loan payments labeled with incorrect currency resulting in wrong amount deducted.
Comment 3 Cristian Oneț 2014-07-31 09:22:14 UTC
I suspect that the conversion rate setup when creating the loan is no used properly. Also found that the loan account currency keeps changing back to the base currency if, while creating the loan, new payees or accounts are created.
Comment 4 Cristian Oneț 2014-07-31 09:26:43 UTC
Created attachment 88049 [details]
Test file that shows this issue.

It seems that when 'SCH000004' (attached to the loan) is created a conversion rate of 1 is used even though the price was entered in the wizard.
Comment 5 Cristian Oneț 2014-09-23 13:35:59 UTC
Today, while fixing BUG 335277, I stumbled upon this 'FIXME' marker https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/ed3ef1673cc960e48949fb310881b74a29ce657a/entry/kmymoney/mymoney/mymoneyforecast.cpp#L1282 which might be the cause of this issue. Since I got my hands dirty recently with multi-currency stuff (BUG 339262) I think I could give this a shot.
Comment 6 Alvaro Soliverez 2014-09-23 13:42:01 UTC
That calcAutoLoan method in MyMoneyForecast is copied from the original one, in MyMoneySchedule IIRC. The fix should go into the original one, which is the one used to calculate payments (the one in MyMoneyForecast is only used for forecasts, not for entering transactions)
Comment 7 Cristian Oneț 2014-09-23 14:04:34 UTC
Thanks for the info Alvaro, it's really helpful :), without it I would have been looking at the wrong place. Nevertheless forecast should also be fixed.
Comment 8 Cristian Oneț 2015-03-29 17:51:17 UTC
A fix is being reviewed at https://git.reviewboard.kde.org/r/123177/
Comment 9 Cristian Oneț 2015-03-31 16:16:18 UTC
Git commit d87427c4e8fad8226c1f1a80bbb094d9cc59a2ab by Cristian Oneț.
Committed on 31/03/2015 at 16:15.
Pushed by conet into branch 'master'.

Properly handle loan payments from accounts using a different currency

If a payment account that has a different currency than the currency
of the loan is selected in the loan wizard, the resulting scheduled
transaction would not have the proper value in the currency of the
payment account.

Fixed this by requesting the user to perform the currency conversion
from the amount of the payment in the currency of the loan to the
amount in the currency of the payment account. This conversion is done
using the standard mechanism provided by the currency calculator.

After this was fixed I observed that the amount of the scheduled
transaction was not being rendered properly in the homepage. Fixed
this by using the same amount formating that is used in the ledger.
REVIEW: 123177

M  +3    -3    kmymoney/views/khomeview.cpp
M  +12   -6    kmymoney/wizards/newaccountwizard/knewaccountwizard.cpp

http://commits.kde.org/kmymoney/d87427c4e8fad8226c1f1a80bbb094d9cc59a2ab
Comment 10 Cristian Oneț 2015-03-31 16:18:32 UTC
Git commit 6fed3349e20c2ce9898058b036b3a20ec90ad033 by Cristian Oneț.
Committed on 31/03/2015 at 16:18.
Pushed by conet into branch '4.7'.

Properly handle loan payments from accounts using a different currency

If a payment account that has a different currency than the currency
of the loan is selected in the loan wizard, the resulting scheduled
transaction would not have the proper value in the currency of the
payment account.

Fixed this by requesting the user to perform the currency conversion
from the amount of the payment in the currency of the loan to the
amount in the currency of the payment account. This conversion is done
using the standard mechanism provided by the currency calculator.

After this was fixed I observed that the amount of the scheduled
transaction was not being rendered properly in the homepage. Fixed
this by using the same amount formating that is used in the ledger.
REVIEW: 123177
(cherry picked from commit d87427c4e8fad8226c1f1a80bbb094d9cc59a2ab)

Conflicts:
	kmymoney/views/khomeview.cpp

M  +3    -3    kmymoney/views/khomeview.cpp
M  +12   -6    kmymoney/wizards/newaccountwizard/knewaccountwizard.cpp

http://commits.kde.org/kmymoney/6fed3349e20c2ce9898058b036b3a20ec90ad033