Bug 224162 - Transaction Match not working?
Summary: Transaction Match not working?
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords: reproducible, usability
Depends on:
Blocks:
 
Reported: 2010-01-25 13:17 UTC by allan
Modified: 2010-05-06 17:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
matchtest.qif file (65 bytes, text/plain)
2010-03-20 17:16 UTC, allan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description allan 2010-01-25 13:17:51 UTC
Version:           3.95 (using KDE 4.3.1)
OS:                Linux
Installed from:    Compiled From Sources

I'm using the 3.95 tarball version (the original, if there's more than one), and am entering some transactions that I have let build up a bit.

I've noticed that for two similar imported items, I can't match them with locally entered investment transactions.  Both pairs have identical dates and amounts.  The match option shows up on the context menu, but with both transactions highlighted, clicking match doesn't perform the match, and no error is flagged.  This happens, as I said, for two transactions, a month 
apart.  They were entered locally as dividends - _DivX - with OFX imported 
bank statements.

openSuse 11.2.
Qt: 4.5.3
KDE: 4.3.1 (KDE 4.3.1) "release 6"
kde4-config: 1.0
Comment 1 allan 2010-01-25 13:20:30 UTC
reported earlier on mailing list
Comment 2 allan 2010-03-03 18:31:53 UTC
Further info.
  This has happened again, and is reproducible.  If the bank statement is imported first, then the dividend payment, both transactions appear and the context menu shows 'match'.  Clicking on match does not do the match.  If I save the file in that state and load it into 1.03, then the match can be completed successfully.

However, If I reverse the order, enter the investment item first, then do the bank statement import, the match happens automatically, and just has to be accepted.
Comment 3 Thomas Baumgart 2010-03-18 10:04:48 UTC
That behavior is by design. You can match a normal transaction against a multi-split transaction but not the other way around. Investment transactions have multiple splits by design, so they have to be present and can automatically be matched against the bank statement of a checking account.
Comment 4 allan 2010-03-18 11:50:26 UTC
(In reply to comment #3)
> That behavior is by design. You can match a normal transaction against a
> multi-split transaction but not the other way around. Investment transactions
> have multiple splits by design, so they have to be present and can
> automatically be matched against the bank statement of a checking account.

But, as I said in my last comment, manual matching works in 1.03.  Are you saying that the design has been changed to stop it working?  If so, why was that?

Also, if it is by design, should not the Match option be disabled?

I'm not asking that the matching be automatic, just that the 1.03 behaviour, of accepting a manual match, be retained.  Thanks.
Comment 5 Thomas Baumgart 2010-03-20 15:13:20 UTC
Sorry, must have misunderstood the issue. Can you provide me with a sample KMyMoney and OFX file, please? I don't have access to OFX sources.
Comment 6 allan 2010-03-20 17:16:44 UTC
Created attachment 41785 [details]
matchtest.qif file
Comment 7 allan 2010-03-20 17:18:15 UTC
It isn't actually an OFX issue.  I just added that to show my meddling wasn't a factor!

In the meantime, that bank has ceased its OFX support, and I now have to import in CSV after all, but the issue is exactly the same.  So I've used my CSV importer to import the transaction, entered a corresponding _DivX payment and attempted to match manually, which failed.  I deleted the imported item, repeated the import and the transaction was matched automatically.  Which way round I attempt to do this normally, depends on the order in which the statements are imported/entered by me.

Using my super-importer, I've produced a single entry qif file, which also shows exactly the same issue, which I've attached.
Comment 8 allan 2010-03-20 17:23:34 UTC
Let me know if you still need a .kmy file, and if so, at what stage, ie. after import and before manual entry or after both entries and failing to match.
Comment 9 allan 2010-04-13 11:53:34 UTC
I now have an additional situation, which is similar in that two matching items, one downloaded, cannot be matched even though that option is showing.  It does not involve investments though.  It relates to a transfer from one bank's cheque account to a savings account, and the transactions are downloaded via OFX.

Initially, both accounts show a single transaction and both are unassigned.  If I enter an account for one of them, the other account now shows the original downloaded item, plus the one created by assigning as receiving account from the 'from' account.  Still one transaction shows as downloaded, the dates are the same, as is the amount.

If I select both, the 'match' option is available, but clicking it does not produce the match.
Comment 10 allan 2010-05-05 18:58:34 UTC
Has there been any change made in this area lately?  I'm seeing a difference, I think.
Comment 11 allan 2010-05-06 17:28:49 UTC
(In reply to comment #10)
> Has there been any change made in this area lately?  I'm seeing a difference, I
> think.

Answering my own query.

Yes, something does now appear to have changed.  I'm on svn1123617.

Originally, when I imported a bank statement which contained the dividend payment, and that dividend had not then been entered as an investment item, on entering the investment, both entries appeared in the current account but manual matching was ignored, and I had to match via v1.03.

Now, by magic, when I do the import with no investment item to match against, it is actually performing the investment transaction activity for me.  No matching needed, it just happens.  Thank you, Anon!