Hi, I use the payee matching feature, in order to automatically assign category, when importing QIF/OFX files. The issue I have is, when importing a QIF file, transactions which match payees, will have the payee changed. For instance, if my transaction is "sncf 01/01/2015 to paris", and my payee is sncf, matching sncf pattern, then my transaction payee will be sncf. It might seems normal, but I lose some valuable information here, like the date of operation "01/01/2015" for instance. For OFX imports, the Payee info gets lost too, but at least I have the info in Memo. Anyway to keep all information from imports? Thank you. Reproducible: Always Steps to Reproduce: 1. Create a payee 2. Create a payee matching pattern 3. (optional) suggest default category 4. import a QIF file containing the pattern/ Actual Results: The transaction's payee gets replaced by the general one Expected Results: 1) The transaction's payee keeps all its data (like date, etc.) 2) OR the original payee gets written to Memo
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Antoine (if you are still using KMyMoney) is this still a problem. There have been changes to the import code, where the "original" payee (whatever field is being used) is maintained in the memo field, just so you don't lose information. If it's actually working OK for you now, you can close this as FIXED, or else just revert it to REPORTED. Thanks
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!
Hi, sorry for the delay. I can confirm the issue is fixed. Tested in KMyMoney 5.1.2. Thanks!
Oups cannot set the status as FIXED. I closed it anyway.
Thanks for confirming. I've adjusted the status.
Hi @Jack, I am sorry to have to reopen this ticket. When I tested to reproduce this bug, I tested on OFX import and yes, from a long time ago, the import of OFX file does a copy of Payee field to MEMO field, even if the MEMO tag is not set in OFX file. However this is not the case for QIF import, which is the original test scenario in description. The QIF import in KMyMoney 5.1.2 does not copy Payee to MEMO field.
*** Bug 463854 has been marked as a duplicate of this bug. ***
Antoine, I'm a bit confused. Is the bug currently that when doing a QIF import with 5.1.2, if the Payee is changed based on matching rules, you lose the information in the original field? I know for sure this was fixed in master branch (which now shows the "Original payee" in the memo. I'll have to check whether that fix was backported to 5.1.3, so if you can test that version, it would help. Also, as far as I know, the changes should apply equally to QIF and OFX, so it's important to know exactly what results you get now. I have not actually tested any qif import in a long time, so I'll have to see if I have any sample data to use.
To make it easier, here is the (corrected) description from bug 463854: -----8<---- STEPS TO REPRODUCE 1. Create a QIF file containing --- D12/12/2022 T-12.10 PCARTE 09/12/22 AGRCST CB*4563 --- 2. Creates a Payee that matches partially on "AGRCST". 3. Import the transaction OBSERVED RESULT Then the import of such event will create a transaction with "Pay to" field of "AGRCST". The date info "09/12/22" is then lost! Which is a critical info. MEMO field provided by bank is empty so it does not contain the date info too. EXPECTED RESULT An option when importing OFX to copy "Pay to" field to MEMO. -----8<---- The problem should be fixed in master with commit https://invent.kde.org/office/kmymoney/-/commit/90ac0dac02 which cannot simply be cherry-picked and needs to be backported.
(In reply to Jack from comment #10) > Antoine, I'm a bit confused. Is the bug currently that when doing a QIF > import with 5.1.2, if the Payee is changed based on matching rules, you lose > the information in the original field? Hi, yes indeed. I know for sure this was fixed in > master branch (which now shows the "Original payee" in the memo. I'll have > to check whether that fix was backported to 5.1.3, so if you can test that > version, it would help. Also, as far as I know, the changes should apply > equally to QIF and OFX, so it's important to know exactly what results you > get now. I have not actually tested any qif import in a long time, so I'll > have to see if I have any sample data to use. Currently, I am using Ubuntu latest LTS (so 22.04 jammy), which officially released kmymoney 5.1.2 (https://launchpad.net/ubuntu/+source/kmymoney) for this distribution version. I could try 5.1.3 but that would require me to test in another VM with Ubuntu 23.10 to setup. Let me a few days for that, when I have freetime :)
First, as Thomas said in his last comment, the patch needs to be backported since it can't simply be cherry-picked. (I'm quite sure this has not been done yet.) This is because the code involving the change has changed too much between the 5.1 branch and master branch. Separately, you can try a newer version with an Appimage (https://kmymoney.org/appimage.html) without the effort of spinning up a new VM. There are appimage versions from both the 5.1 and master branch available.
Ok, I tested with https://binary-factory.kde.org/view/AppImage/job/KMyMoney_Release_appimage-centos7/lastSuccessfulBuild/artifact/kmymoney-5.1-607-linux-gcc-x86_64.AppImage . Version info shows: 5.1.3-2fecc3fb5 The issue is reproducible. Test scenario: 1. create a new account file 2. create a QIF file D12/12/2022 T-12.10 PCARTE 09/12/22 AGRCST CB*4563 ^ 3. import the qif file As a result, the payee is unchanged and the memo field is empty. Another test: if I add a Payee that matches the pattern (here AGRCST), and delete and reimport it, then the Payee is recognized but the MEMO field is still empty. So the KMyMoney 5.1.3 give the same symptoms as 5.1.2.
I'm sorry if it wasn't clear enough, but this patch is not yet available in the 5.1 branch, so you will continue to see the problem in 5.1.3 and even the nightly build from the 5.1 branch. It is only available in master branch, which will eventually be released as 5.2, but there is not yet a specific timeline for this.
(In reply to Jack from comment #15) > I'm sorry if it wasn't clear enough, but this patch is not yet available in > the 5.1 branch, so you will continue to see the problem in 5.1.3 and even > the nightly build from the 5.1 branch. It is only available in master > branch, which will eventually be released as 5.2, but there is not yet a > specific timeline for this. Hmm if I am looking at the build related to my test: https://binary-factory.kde.org/view/AppImage/job/KMyMoney_Release_appimage-centos7/607/ , it looks to me like the build is done against master branch, not 5.1 branch. The version showed in KMyMoney help might not be updated to reflect the master branch (it should have been 5.2-SNAPSHOT or something similar).
> Hmm if I am looking at the build related to my test: > https://binary-factory.kde.org/view/AppImage/job/KMyMoney_Release_appimage-centos7/607/ > , it looks to me like the build is done against master branch, not 5.1 branch. The version > showed in KMyMoney help might not be updated to reflect the master branch > (it should have been 5.2-SNAPSHOT or something similar). The problem is, that the branch information shown on this Jenkins page is not the one of the source code but of the build scripts. They have nothing to do with the software. The version info in the about dialog (help) is auto-generated, reflects the source and is correct (see following list) KMyMoney_Release_appimage --> built daily using KMyMoney stable branch (version in about dialog (currently) shows as 5.1.3-xxxxx) KMyMoney_Nightly_appimage --> built daily using KMyMoney master branch (version in about dialog (currently) shows as 5.1.80-xxxxx)