If an imported transaction ends up having splits in accounts having different currencies a conversion rate of 1 is used instead of the available conversion rate at the date of the transaction. Reproducible: Always Steps to Reproduce: 1. Use the attached file 2. Import multi-currency.qif in the file Actual Results: A transaction with both splits having the value '10' RON and EUR is added. Expected Results: A transaction with one split having the value '10' RON and the other having the value '2,27' EUR should be added.
Created attachment 88770 [details] Test kmymoney file Use this file to test the bug.
Created attachment 88771 [details] Test import file
Created attachment 88772 [details] Test import file Import this into the RON account, the transfer is created using the payee matching mechanism.
Correction of the expected results. A transaction with one split having the value '10' EUR and the other having the value '43,98' RON should be added.
Git commit 5099dba32f951752d86ddf1b8732fbab8375215e by Cristian Oneț. Committed on 21/09/2014 at 09:03. Pushed by conet into branch 'master'. Perform currency conversions if necessary when importing transactions. An imported transaction might have splits in accounts having different currencies. If this is the case set the shares of the split using the best conversion rate which is available at the date of the transaction. M +32 -6 kmymoney/converter/mymoneystatementreader.cpp http://commits.kde.org/kmymoney/5099dba32f951752d86ddf1b8732fbab8375215e
[From Dev List] I'm having difficulty importing a particular transaction. It is an example of a regular transaction, where the payee name often varies. I have the matching set up to include a few variations. In this particular case, the payee is 'FIDELITY FNW INC ' and I have an entry to match that to 'FIDELITY'. There is no default account. This is what happens on import - Statement with 1 transactions ready. KMyMoneyPlugin::KMMStatementInterface::import start Importing statement for 'NatWest Current Plus 8355' Processing transactions (NatWest Current Plus 8355) Process on: '2015-03-02', id: '2015-03-02-7fafe70-1', amount: '40.09', fees: '0.00' Start matching payee Found match with 'FIDELITY FNW INC' on 'FIDELITY' Single matches Adding second split to Artemis High Income(A000454) Setting second split shares to E000002 -49.56 Looking for a match with transaction: "2015-03-02" , "FIDELITY" , "40.09" (referenced account: "NatWest Current Plus 8355" ) Considering 0 existing transaction(s) for matching Looking for a match with transaction: "2015-03-02" , "FIDELITY" , "40.09" (referenced account: "NatWest Current Plus 8355" ) Considering 17 schedule(s) for matching the transaction Processing transactions done (NatWest Current Plus 8355) Importing statement for 'NatWest Current Plus 8355' done So, what has happened is that a Sell transaction has been created, for the amount of £40.09, and a Quantity of 49.56 has been invented. I can't see any reason why this should happen. There are reinvest dividend transaction referencing both accounts. _______________________________________________________________________________________________________ [Cristian] I'm guessing that the transaction is created with a quantity of 49.56 because between the £ of and E000002 there is a price of 49.59/40.09=1.236. Is that true? Please check your price entries. This was added to fix BUG 339262. ______________________________________________________________________________________________________ [Allan] That could be a clue. If I open the split editor on this transaction, I'm presented with the price editor, showing Currency GBP to GB0006838097, To amount = 49.56, Price £1 = 1.2362, GB0006838097 1 = £0.8089. The last price I have, for 2 Feb, is 0.8089. ____________________________________________________________________________________________________ [Allan] I don't know if this is correct, or good enough, or sufficient,but what I've done is, after line 1135 MyMoneyAccount splitAccount = file->account(s.accountId()), I've added if (!splitAccount.accountType() == MyMoneyAccount::Stock) { to bypass the following four lines. Then, deleting the already imported transaction and re-importing, all looks good. I wondered if MyMoneyAccount::Investment might also need including/excluding. Or, perhaps I'm missing something.
I was about to add my proposed fix. So, to be able to test afterwards, I tested first. Using the same files, I cannot now reproduce this issue. The file I was intending to edit was mymoneystatementreader.cpp, and this has had no change since January. So, I await further developments.
(In reply to allan from comment #7) > I was about to add my proposed fix. So, to be able to test afterwards, I > tested first. > > Using the same files, I cannot now reproduce this issue. The file I was > intending to edit was mymoneystatementreader.cpp, and this has had no change > since January. > > So, I await further developments. Eventually if you are going to do anything please don't write this: !splitAccount.accountType() == MyMoneyAccount::Stock use this instead: splitAccount.accountType() != MyMoneyAccount::Stock
I can now reproduce this issue. What was needed was an existing transaction to match against. However, this time the match was a valid one. So, no fix for the time being. We'll see if a nasty crops up again sometime.