I wanted to leave Money and start using Kmymoney (which seems to be great), but it changes payees during QIF import. Example: if the file contains a transaction to a payee named "Pool" and later on another transaction to a payee named "Accommodation in Liverpool" it changes this payee to "pool". This happens in all cases where there is a part of the string contained in another (previous or already existing) transaction. This way it makes all the records useless.The QIF file still has the correct payees so it is definitely the import that does it. I spent hours and hours studying forums and trying to find a way of switching this erroneous matching off but with no result. Therefore I believe this is a bug. Reproducible: Always Steps to Reproduce: 1. each time I try to import a QIF file (exported from MS Money 97) 2. 3. Expected Results: Respect the payees as specified in the QIF file for each transaction.
If we take your example, 'Pool', look for it in the Payees view. Click the Matching tab, and set to not do matching. See if that helps with that item. I don't know of any global switch for this, but perhaps someone else may. You could try Settings/Configure KMM/Ledger/Import and set match transactions within days to zero. I wouldn't say this was a bug, as some users will use it to simplify like imported payees, but I can see your problem, so it might be an idea to change this classification to 'wishlist'.
I agree with Allan it's not a bug, although it might be an unintended consequence of the design. However, I think it's important to know exactly how this happened. If you can provide a minimal test case, it would help. In particular, if you have a QIF file with the two transactions, one for "Pool" and one for "Liverpool" and neither payee exists in the kmy file, when you import the QIF, does it create one or two payees? If both "Pool" and "Liverpool" payees exist, and you import another QIF which includes both (different transactions, so we don't conflate payee matching with transaction matching) do they get assigned to the correct payees or both to "Pool"? Also, if the "Pool" payee was automatically created by the first import, what are the payee matching settings for that payee?
https://docs.kde.org/stable4/en/extragear-office/kmymoney/details.payees.personalinformation.html#idp47586976 states the details how this is designed, though if I read it now, I am unsure if the second option (Match on Payee Name) should require to match the full string or just parts of it, though the example provided suggests that a part is fine. I do agree, that the behavior is not ideal for the given use case of the OP.
I would expect "Match on Payee Name" to require a full match of the string. "Match on name listed below" should (in my opinion) accept a partial match - and we might consider changing this label to "Match on a string listed below." I can imagine a wishlist to add matching by regexp, in which case you could use ^ and $ to require matching the full string. I would also point out to the OP that KMM has not changed the payee name - the issue is whether the payee name in the import file is matched to some existing payee or is simply used as a new payee.
On 22/08/15 15:52, Thomas Baumgart wrote: > https://bugs.kde.org/show_bug.cgi?id=351511 > > --- Comment #3 from Thomas Baumgart <ipwizard@users.sourceforge.net> --- > https://docs.kde.org/stable4/en/extragear-office/kmymoney/details.payees.personalinformation.html#idp47586976 > states the details how this is designed, though if I read it now, I am unsure > if the second option (Match on Payee Name) should require to match the full > string or just parts of it, though the example provided suggests that a part is > fine. I do agree, that the behavior is not ideal for the given use case of the > OP. > In the Ledger/Data entry settings, there is a setting to Match names from start. I wonder if that might help. No, I doesn't look like it. Allan
@Allen: no, that option is only used during manual data entry @Jack: no need for a regexp-wishlist entry - that is exactly how it is implemented. And that is the cause of the problem here, as it does a partial match. So in case you have an import into an empty file which contains 'Pool' and 'Liverpool' as two payees, than it depends on the order in the QIF file if you end up with one (order: Pool, Liverpool) or two payees (order: Liverpool, Pool). Changing the behavior so that "Match on Payee Name" requires a full match of the string is easy to accomplish (source-code wise). If it is general consensus that this is how the application should behave, than I go ahead and change it. Here is a comment located at the automatic payee creation in MyMoneyStatementReader: // for now, we just add the payee to the pool and turn // on simple name matching, so that future transactions // with the same name don't get here again. Changing the "Match on Payee Name" to require a full match does not hurt here at all and I don't see other cases where it would be a problem to change it. If not wanted by the user, he can always change it to the "Match on a string in a list" version, which supports both, partial and full, match versions out of the box. Comments?
I think making the match on name require a complete match makes sense. If you want a partial match, you can use the lower section, and perhaps the label could better reflect that. The OP also seemed to imply that the original payee in the QIF file was not being kept as part of the memo field. If the match on payee name is exact, this shouldn't matter, but if it uses a partial match, I can see not wanting to lose this information.
Created attachment 94300 [details] QIF file plus result after import
Gentlemen, thank you for responding to my report. Switching off the matching for a payee did solve the issue as the import rather shockingly created another payee of the same name in the payee list instead! (Plus how can I change payee's settings if no payees exist in kmymoney before importing a qif file?) Any idea of how to get around this and to import my historical data without corruption? Or should I wait until full-string payee matching is incorporated in the software? Anything else I could do? I am sorry, but kmymoney is unusable at the moment if the import function changes my payees, by this also their categories and thus makes all my historical data false. Thanks for your suggestions. Tom
Created attachment 106370 [details] QIF test file
With the appended test case it could be verified that this bug has been fixed with commit http://commits.kde.org/kmymoney/dd85d3b1ee08c0d3499b840b655d9500c0f07ac5 from bug 374352.