Summary: | Transactions which are clearly unrelated are automatically matched. | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | David Chamberlain <dc46and2> |
Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 4.5.3 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
A small KMyMoney data file
An OFX update to import |
Description
David Chamberlain
2011-07-29 04:51:13 UTC
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. |