Hi, I switch from ubuntu 16.04/kmymoney 4.6 to xubuntu18.04/kmymoney5.0 in may and I think that this new version has some bugs I import all my transactions into kmy every month from my bank I have about 10 schedule transaction every month and I feel that the transactions recognition is not as efficient as it was before I don't know how to give more details about this situation antoine@Frankenstein:~$ apt show kmymoney Package: kmymoney Version: 5.0.1-2 Priority: optional Section: universe/kde Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
Some example this month; I had 6 scheduled transactions. When I imported a qif file, 4 of them matched and 2 failed to match. Data in qif file and scheduled transaction are similar and I do not know why these 2 transaction did not match (see attachment).
Created attachment 114723 [details] exemple1
Created attachment 114724 [details] example2
Both of your examples show scheduled future transactions. Scheduled transactions are not really in the ledger until they are entered. Until that happens, the matching mechanism doesn't see them. I don't believe this behavior has changed - are you sure that with 4.6 you had not already entered the transactions from the schedule before trying to match them with imported ones?
I am not sure I completely understood your message. Date format is dd/mm/yyyy, so they are both past transaction. I never enter transaction and only import transaction from qif.
It might help if you read the section of the manual about schedules. Unfortunately, I do not have a direct link to the French version. When you create a schedule, you are not creating any actual transactions, only virtual transactions. (I'm not sure that is really a good term to use, but I can't think of anything better.) In order to create a real transaction in the ledger, you need to "Enter" the transaction, at which time you confirm all the details (especially if any of the items, such as amount, are estimated, and might change every month, for example. In your attachment, you have clicked on the name of the schedule, so you can edit the details. The bottom section of your screen shot says "Palements en retard" which I think is "Overdue transactions" in English. Look at the two icons between the date and the name of the schedule. The first one is to enter the transaction. Click on it and it will pop up a dialog similar to the one in your screen shot, you can adjust any details, and when you click OK, it will create that real transaction in the ledger. After you have done that, it becomes available for matching on import. Also - look at the checkboxes on the lower part of that dialog. If you check the second one, the transaction will be set for the last day of the month, varying between the 28, 19, 10, or 21, as appropriate. If you check the third one, the "entering" of the transaction will happen automatically, so you don't need to remember to do it manually. This is generally only good if the details do not change each time. Finally, now that I have been thinking more about this, I do recall that when I do an import, I sometimes get a pop-up saying that there are overdue scheduled transactions, and do I want to enter them before doing the import. I rarely see this, because I do check for overdue transactions when I open KMM. I wonder if it is possible that this check is no longer happening. If so, that would be a regression. Do you remember ever seeing such a notice?
Created attachment 114729 [details] example3_1
Created attachment 114730 [details] example3_2
"I do recall that when I do an import, I sometimes get a pop-up saying that there are overdue scheduled transactions, and do I want to enter them before doing the import." This is how O use KMM to match my scheduled transactions. For example, I have a good match with example3 (see attachments)
Created attachment 114738 [details] Example of payee matching From reading through the history of this entry a few times now and analyzing the code base I expect the strange behavior antoine is experiencing to be tied to payee matching. If both transactions have a payee (and from the screenshot it looks they do) they must match. The name of the payee used in the KMyMoney file and the name provided by the bank might be totally different (as in antoine's examples). That is where payee name matching comes into play. Attached is an example on how this could look like if the payee information in the statement varies over time. @antoine: can you check the payee matching settings for a transaction where the match works (e.g comment 7) and where it does not (comment 2 and comment 3).
Created attachment 114858 [details] example1_2
Created attachment 114859 [details] example2_2
Created attachment 114860 [details] example3_3
Thank you, now I understand why it wasn't working. Sorry for bothering you. I guess my bank changed payee informations and it explains why matching was not working well.
Should this be closed as WORKSFORME or some other status?
I chose "Not a bug", I was not using KMM in the right way