When importing more than a few transactions, KMM seems to think unrelated transactions are associated to certain scheduled transactions. After hitting the Import button and selecting the account to import the transactions into, I am presented with a popup for each of the 1000 transactions to import from the CSV file, with KMM asking: "KMyMoney has found a scheduled transaction named Provincial Income Deductions which matches an imported transaction. Do you want KMyMoney to enter this schedule now so that the transaction can be matched?" There are no reasons for this message to appear. The payees are TOTALLY different (no similarity whatsoever like "Donut Restaurant" & "Renovation Store"), the only common point is the account where the scheduled transaction is programmed to apply to and the account I want to import to from the CSV... Reproducible: Always Steps to Reproduce: 1.Create a CSV file 2.Import in KMM 3.KMM tries to match the imported transactions with certain scheduled transactions that have no link whatsoever Expected Results: KMM should not ask to match unrelated transactions together. Happens with 4.6.1 & 4.6.4
Again, transaction matching is a function of KMM, not the CSV plugin, so I have taken the liberty of editing your bug heading, as I think it is misleading and could cause it to be disregarded by the appropriate developer. Where the bogus matching occurs, are the values similar? I think to progress this it will be necessary to see a kmy file and data file that can can demonstrate the problem. The choice here is either to manufacture a new file without your personal data, and a suitable CSV file which together show the problem. Or, to save your existing file in anonymized format (via the file selector filter) and provide a demonstartion CSV file, again which show the problem, and indicating the relevant accounts involved. If the files are fairly large, please compress them before attaching to the bug entry.
" I have taken the liberty of editing your bug heading" Absolutely my friend! I agree, if it has nothing to do with the CSV plugin, then its logical! "Where the bogus matching occurs, are the values similar?" Not even close. KMM is trying to match my scheduled income tax transaction (which is unfortunately several hundreds of dollars) with small restaurant transactions that are all in the neighborhood of 10$-20$... I am struglling to find time to debug & troubleshoot these days... When I have a few minutes to spare, I will produce a test set with a kmy file and a corresponding CSV file and attach it here!
Teething problems, I'm afraid. We'll try to sort everything out, when you are able.
Same problem here using online banking functions via KBanking (but only if the values are similar) - it would be helpful to give the user a chance to decide by giving him some more informations, not only the name of the scheduled transaction. eg: both payees both values category and memo of scheduled transaction Additional wish: If there is more than 1 similar transaction, give the user a choice to select the correct one. My current "lesson learned" is: don't say "yes" if KMM ask to enter a scheduled transaction on importing transactions
If either of you is able to compile from source, it might be worthwhile trying to install the development version from Git. There has been a significant rework in this area, which may be helpful for you both. For instance, here's the message box message now - " QString questionMsg = i18n("KMyMoney has found a scheduled transaction which matches an imported transaction.<br/>" "Schedule name: <b>%1</b><br/>" "Transaction: <i>%2 %3</i><br/>" "Do you want KMyMoney to enter this schedule now so that the transaction can be matched? ", scheduleName, splitValue, payeeName);" That looks like it gives you what you want.
I have the same problem, but I think I can see something which clearly is wrong. It looks like the period over which to match (set to 4 days in my case) is not being obeyed. e.g. KMM has matched transactions Bank Entry: 2013-03-22 Your Entry: 2013-01-27 I don't know whether this is significant, but my date format is DD/MM/YYYY, not the US MM/DD/YYYY
On 21/12/13 12:51, m.d-b@mail.adsl4less.com wrote: > https://bugs.kde.org/show_bug.cgi?id=327497 > > m.d-b@mail.adsl4less.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |m.d-b@mail.adsl4less.com > > --- Comment #6 from m.d-b@mail.adsl4less.com --- > I have the same problem, but I think I can see something which clearly is > wrong. It looks like the period over which to match (set to 4 days in my case) > is not being obeyed. > > e.g. KMM has matched transactions > > Bank Entry: 2013-03-22 > Your Entry: 2013-01-27 > > I don't know whether this is significant, but my date format is DD/MM/YYYY, not > the US MM/DD/YYYY > I don't think your date format is likely to be relevant, as within KMM, a standard format is used, I think, apart from at input. This bug relates to the matching against scheduled transactions. So no-one is led astray, I thought it best to ask for confirmation. Are you able to provide console output relating to your error? That could be helpful. Allan
Hi Allan. Yes, it is with respect to scheduled transactions that I am seeing a problem. Rather than matching a bank transaction (from imported CSV) with a scheduled transaction within 4 days, completely unrelated transactions that may be months apart are being matched just based on value. I don't believe an error is logged on the console, it is just that the end result is wrong - would you like me to attach a screenshot? Mark
On 22/12/13 14:41, m.d-b@mail.adsl4less.com wrote: > https://bugs.kde.org/show_bug.cgi?id=327497 > > --- Comment #8 from m.d-b@mail.adsl4less.com --- > Hi Allan. Yes, it is with respect to scheduled transactions that I am seeing a > problem. Rather than matching a bank transaction (from imported CSV) with a > scheduled transaction within 4 days, completely unrelated transactions that may > be months apart are being matched just based on value. > > I don't believe an error is logged on the console, it is just that the end > result is wrong - would you like me to attach a screenshot? > > Mark > Hi Mark Generally, on the console there is a commentary on what transaction is being matched, and what is being considered. It was that that I thought might be helpful. However, I'm unable to reproduce the problem here. What really is needed is a copy of the import file and .kmy file which show the problem. If the .kmy file has been anonymised, then I don't think it's likely that anything will match it, so it would need to be a non-anonymised file, and import file to match, but without sensitive information. Then, there's another however. Because there will be no further bug fix releases for the 4.6 branch, and because the current development branch has had considerable work done in the matching area, I'm afraid the advice has to be either, compile the development version, or await the release of version 4.7, for which presently no date has been set. Allan
Hi Allan. Sorry for the very long delay in responding, but I've been too busy on other things to try building 'til now. I've downloaded from git and have 4.6.90-c3124ff237. Is that an appropriate branch to use for testing to see if it is already fixed? All the best, Mark
Test to see if this has stopped the bugtracker inserting my e-mail address instead of name
4.6.90-c3124ff237 now doesn't match anything, even with exactly the same amount on the same day. Is there a new option that is set to disable matching by default?
On 25/01/14 21:59, mark wrote: > https://bugs.kde.org/show_bug.cgi?id=327497 > > --- Comment #12 from mark <m.d-b@mail.adsl4less.com> --- > 4.6.90-c3124ff237 now doesn't match anything, even with exactly the same amount > on the same day. Is there a new option that is set to disable matching by > default? > Have you checked the Matching tab for that payee? That's not a recent option, however, but the setting might need to be looked at. So far as the two transactions are concerned, are there any splits that might be different? Allan
(In reply to comment #10) > Hi Allan. Sorry for the very long delay in responding, but I've been too > busy on other things to try building 'til now. I've downloaded from git and > have 4.6.90-c3124ff237. Is that an appropriate branch to use for testing to > see if it is already fixed? > > All the best, > > Mark Yes, that's very recent.
Marking this as a regular bug. An update of the issue's state might also be necessary.
Mark could you report back on this issue using version 4.7.0 which should contain the changes needed to fix this. Also please check out this thread https://forum.kde.org/viewtopic.php?f=69&t=123443 about transaction matching.
Hi Christian. I'll do so as soon as I get chance. I either need to wait for Mageia to send out 4.7.0 or do a 64-bit build on the new version (I've changed from 32 to 64 bit architecture since originally raising this). All the best, Mark
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 set the bug status 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!
Dear Bug Submitter, 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!