Bug 327497 - When importing transactions, KMM seems to think unrelated transactions are associated to certain scheduled transactions.
Summary: When importing transactions, KMM seems to think unrelated transactions are as...
Status: RESOLVED WORKSFORME
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.6.4
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2013-11-12 12:43 UTC by lp.allard.1
Modified: 2018-10-27 02:05 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lp.allard.1 2013-11-12 12:43:16 UTC
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
Comment 1 allan 2013-11-12 13:20:31 UTC
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.
Comment 2 lp.allard.1 2013-11-12 15:36:17 UTC
" 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!
Comment 3 allan 2013-11-12 17:20:26 UTC
Teething problems, I'm afraid.  We'll try to sort everything out, when you are able.
Comment 4 Frank 2013-11-27 07:24:00 UTC
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
Comment 5 allan 2013-11-27 11:18:30 UTC
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.
Comment 6 mark 2013-12-21 12:51:38 UTC
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
Comment 7 allan 2013-12-21 16:32:20 UTC
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
Comment 8 mark 2013-12-22 14:41:21 UTC
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
Comment 9 allan 2013-12-22 17:06:33 UTC
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
Comment 10 mark 2014-01-25 20:33:04 UTC
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
Comment 11 mark 2014-01-25 20:37:39 UTC
Test to see if this has stopped the bugtracker inserting my e-mail address instead of name
Comment 12 mark 2014-01-25 21:59:06 UTC
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?
Comment 13 allan 2014-01-25 22:08:40 UTC
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
Comment 14 allan 2014-01-25 22:11:08 UTC
(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.
Comment 15 Cristian Oneț 2014-09-23 13:57:15 UTC
Marking this as a regular bug. An update of the issue's state might also be necessary.
Comment 16 Cristian Oneț 2014-10-29 14:11:01 UTC
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.
Comment 17 mark 2014-10-30 21:07:20 UTC
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
Comment 18 Andrew Crouthamel 2018-09-25 03:45:04 UTC
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!
Comment 19 Andrew Crouthamel 2018-10-27 02:05:20 UTC
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!