Version: 4.5.3 (using KDE 4.6.2) OS: Linux I encounter this bug when a transfer occurs between two accounts that are updated via OFX. A separate transaction representing the transfer is downloaded into each account, but KMyMoney does not allow matching between two downloaded transactions. In order to work around this limitation, I usually update one account, then "edit" any transfer transactions so they become "manually entered" transactions, then update the second account. However, the next month, when a new transfer transaction is downloaded, it gets erroneously matched with clearly unrelated transactions in the second account. It matches: 1. Transactions from different time periods (e.g. 2009-06-25 with 2011-05-12) 2. Transactions of different amounts (e.g. $1000 with $1550) 3. Transactions which have already been matched with other transactions There is a configuration setting under Ledger/Import called "Match transactions within days" which I have set to 3. Reproducible: Always Steps to Reproduce: I will attach two sanitized files for reproducing the bug. Open data.xml with KMyMoney. Notice the (correctly) matched transaction in the Savings account. Now import update.xml into the Checking account. Notice the new matched transaction in the Savings account has all three problems that I mentioned above. Actual Results: Obviously unrelated transactions are matched. Expected Results: Correct transactions should be matched, or no matching should occur at all. It would also be nice if two transfer transactions could be matched even if they were both "downloaded". OS: Linux (x86_64) release 2.6.38-10-generic-tuxonice Compiler: cc
Created attachment 62288 [details] A small KMyMoney data file
Created attachment 62289 [details] An OFX update to import
David: thanks for the sample files. They helped a lot. The problem is, that for the imported transfer transaction the checking account is scanned backwards to find the 'category' for the downloaded transaction by looking for similar transactions. This scan finds the (still unaccepted) match of a previous transfer and copies the corresponding split. During this copy, the match information of the previous transfer is also copied (which is wrong) and thus the weird match information is shown and confuses the user. So this part is solved by simply removing the match information during import (a one line change that I will add to SVN trunk in a minute). Can you provide another sample file (set) that shows the problem with non-matching two imported transactions? I actually thought we have this under control. It would be nice, if you can do that in a rather short period of time as we are in the process of releasing a stable version. Adding more files to this bug entry and a short explanation on how to reproduce the problem will do just fine. Until then, I leave this item open.
I wasn't able to reproduce the non-matching of 2 imported transactions bug, so maybe you do have it under control. I had assumed that because two imported transactions cannot be manually matched, they would never be automatically matched either. However, during my testing, the second transaction was simply marked as a duplicate and not imported. While this is not matching per se, it does produce the desired result. If I have any issues with this in the future, I will file a new bug report. Thank you for your time and effort--KMyMoney is an eminently useful application.