When importing a list of transactions in OFX format, new payees are replaced by an incorrect match. The matched payee seems random (in my case last seen in a five year old transaction) but is always the same for all new payees and across different import operations. Reproducible: Always Steps to Reproduce: 1. Import OFX file containing previously unknown payees 2. Check that new payee is replaced by existing unrelated payee Actual Results: Payee is imported incorrectly Expected Results: New payee should have been created consistent with account being imported into. It is possible that this is related to the specific format of my imported file, but happens with OFX and QFX import from different banks. The exact payee also appears in the memo field, but I have to cut and paste it into the payee field for each incorrect transaction.
OFX and QFX are different names for essentially the same format. If multiple transactions are being matched to the same payee, please check that payee to see if there is an extra matching entry with perhaps just a single blank. In the Payees view, select the payee to which everything is matching, then select the "Matching" tab, and see if there is an entry which might (inappropriately, but correctly) match all the imported transactions. I don't remember the details, but I remember this being found as a problem in the past.
Does this sound like Bug 348635 - CSV Importer can create Payee consisting of a single or multiple space leading to erroneous matching? A fix for this was committed last June and should be in the next stable release.
Jack: Yes, I did think of that. *All* new payees are matched to the same existing one. That would require a universal wildcard expression in the payee's matching tab. There is nothing at all. I tried checking "No matching" to see if it makes a difference. It just matched with another wrong payee.
Allan: No. I do not have a " " Payee, and the payee to which it matches all unknown (new) payees are "IBERIA" in one kmm file and "SUNOCO 0498589 WORCESTER M" in another kmm file. Also, this is OFX, not CSV, although I would not be surprised both use the same matching code.
Also, I did not have this problem with KMM 1.05. It appeared the day I switched to KMM 4.6
(In reply to Jan from comment #4) > Allan: No. I do not have a " " Payee, and the payee to which it matches all > unknown (new) payees are "IBERIA" in one kmm file and "SUNOCO 0498589 > WORCESTER M" in another kmm file. Also, this is OFX, not CSV, although I > would not be surprised both use the same matching code. My fix was within the CSV plugin code, to remove potentially troublesome blank payee names, so before any matching. It could be that the OFX code has the same issue, although it does look like your problem is not the same.
(In reply to Jan from comment #5) > Also, I did not have this problem with KMM 1.05. It appeared the day I > switched to KMM 4.6 Long-standing then. As I don't use OFX, it would be very useful if you could provide a mini .kmy file that demonstrates the problem, and also a simple OFX file too.
Please switch to 4.7.2 before any more checks/tries. I kind of remember that we had a change in the matching code.
Before I upgrade, I just wanted to add this: 1. I ran KMM from the console: it prints matching info in the terminal. Every time a match is found, two false matches are listed and one or zero correct matches. If there is a third match, the result is always good; if there isn't, it's always wrong. 2. If I disallow matching for these two incorrectly matching payees, or change it to "Match on name," everything works. The original matching settings for these two payees was "Match on a name listed below", but the list was empty (not even blanks) and all options in the list [add, remove, up, down] were grayed out. 3. When I then reset the original matching (match on name listed below), I could no longer reproduce the problem, even if the prints in the terminal still included both payees in all matches found. The difference is that now a new payee was created, as expected. So, swapping payees that match on an empty list back and forth to either no match or match on name solves the problem. Matching on an empty list always leads to a match detection, but not always to an incorrect result. Before changing the matching, an incorrect match was generated; after a back-and-forth, a new payee was created. Is this explained by the 4.7.2 change? If so, please close the bug. Thanks!
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!