Bug 339262

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.