Per Hei Ku's request, I'm opening a separate thread for this. I don't know if perhaps I'm doing something wrong or if the operation just doesn't match the documentation. Perhaps someone who's more experienced can shed some light.

I am trying to figure out how transaction matching works. I have some credit card payments that appear in my imported credit card QIF and also in my imported bank statement QIF. They are separated a couple days from each other. As far as I can figure out these still need to be matched by hand.

playing a bit more with the matching, I found....
My imported bank statements/ledger did not have payee or category information. (The Memo field contained the imported text notes.) After I set the Pay to (credit card payee) and Transfer to (my credit card category), this transaction appeared in my credit card ledger. So then, when I switched to the credit card ledger, two transactions were listed. Apparently, one of these was then considered non-imported because I was allowed to select the two transactions and select Match.

As a test subject, if I duplicate a transaction, then edit the date (to try to make it appear "hand-entered"), I am still not allowed to perform a match between the duplicate and the original. If I set the From or To field, I am still not allowed to match.

However, once I assign a category in one of the transactions, I am able to perform matching with it, even if the From or To field is empty. So it seems to me that the important thing in order to allow a transaction match is the category assignment.

So, I think this is incorrect...

The solution is to tell KMyMoney that the transactions are the same, using the manual matching interface. This allows you to match an imported transaction with a hand-entered (non-imported) transaction.

[s]To do so, right-click on one of the transactions to be matched. Choose Match Transactions... from the context menu. This flags the selected transaction, and changes the background color to a nice pale green.

Next, right-click on the other transaction to be matched. Choose Match with this Transaction. This will match the two transactions together. The values of both transactions must be the same for the match to work.[/s]

For me it is working more like this....

To match two transactions, select both of the transactions to be matched. Then right-click on one of them and select Match.

Transaction matching requires all of the following to be true:

• One transaction must be imported
• One transaction must be manually entered (non-imported). If you manually select a category in a transaction KMyMoney recognizes it as manually entered.
• The values of the two transactions must be equal.

Note

In the future, matching will be made more automatic. The importer will automatically match transactions which look like the same, and give you the option to un-match them.

[s]Note

The matching interface will not allow you to match two transactions which have both been imported. Likewise, it won't allow matching between two transactions which have both been entered by hand.[/s]

Wow, a lot of stuff to read and understand ... and then map to the logic of the program Hopefully, my comments make sense to you. If not, please feel free to continue the discussion.

drewkeller wrote:I am trying to figure out how transaction matching works. I have some credit card payments that appear in my imported credit card QIF and also in my imported bank statement QIF. They are separated a couple days from each other. As far as I can figure out these still need to be matched by hand.

Not necessarily. Depending on your actual data, the QIF importer together with the statement reader could assign a category automatically. For this to work, the QIF data needs to provide data for the payee. As you mention, this is not the case with your bank statement. Hence all transactions imported that way should have no payee and no category assigned and once they have a value different from 0 you should see an exclamation mark on a yellow triangle showing that somethings not balanced with this transaction.

If you assign a category (or the credit card account in your case) to this imported transaction, it will be balanced. If you work this far and now import the QIF of your credit card, matching should take place automatically in case the value of the transaction is the same.

Since you imported the second (credit card) QIF file before you fixed the transaction in the bank account, there was no reference of this transaction to the (KMyMoney) credit card account and thus could not be matched automatically.

drewkeller wrote:playing a bit more with the matching, I found....
My imported bank statements/ledger did not have payee or category information. (The Memo field contained the imported text notes.) After I set the Pay to (credit card payee) and Transfer to (my credit card category), this transaction appeared in my credit card ledger. So then, when I switched to the credit card ledger, two transactions were listed. Apparently, one of these was then considered non-imported because I was allowed to select the two transactions and select Match.

This goes nicely along with the explanation above.

drewkeller wrote:As a test subject, if I duplicate a transaction, then edit the date (to try to make it appear "hand-entered"), I am still not allowed to perform a match between the duplicate and the original. If I set the From or To field, I am still not allowed to match.

That makes sense, because the original transaction is still matched. One can see that because the Unmatch button is active for this transaction. As long as you have a transaction in that state you cannot match it with a second transaction. Once you accept the transaction, it will be a normal imported transaction and you might be able to match it against another manually entered transaction. I used might here, because I don't know if that is really the case and cannot duplicate it right now.

drewkeller wrote:However, once I assign a category in one of the transactions, I am able to perform matching with it, even if the From or To field is empty. So it seems to me that the important thing in order to allow a transaction match is the category assignment.

This needs some more investigation as it should not happen.

drewkeller wrote:So, I think this is incorrect...

The solution is to tell KMyMoney that the transactions are the same, using the manual matching interface. This allows you to match an imported transaction with a hand-entered (non-imported) transaction.

[s]To do so, right-click on one of the transactions to be matched. Choose Match Transactions... from the context menu. This flags the selected transaction, and changes the background color to a nice pale green.

Next, right-click on the other transaction to be matched. Choose Match with this Transaction. This will match the two transactions together. The values of both transactions must be the same for the match to work.[/s]

For me it is working more like this....

To match two transactions, select both of the transactions to be matched. Then right-click on one of them and select Match.

Transaction matching requires all of the following to be true:

• One transaction must be imported
• One transaction must be manually entered (non-imported). If you manually select a category in a transaction KMyMoney recognizes it as manually entered.
• The values of the two transactions must be equal.

Note

In the future, matching will be made more automatic. The importer will automatically match transactions which look like the same, and give you the option to un-match them.

[s]Note

The matching interface will not allow you to match two transactions which have both been imported. Likewise, it won't allow matching between two transactions which have both been entered by hand.[/s]

That (the red part) is basically true except for the assignment of a category making the transaction manually entered. Also, if a scheduled transaction exists for the given post date but has not yet been entered into the ledger, the user will be asked if he wants to enter and match it.

ipwizard wrote:

drewkeller wrote:However, once I assign a category in one of the transactions, I am able to perform matching with it, even if the From or To field is empty. So it seems to me that the important thing in order to allow a transaction match is the category assignment.

This needs some more investigation as it should not happen.

Now that I'm a bit more familiar, From/To might not actually have been empty. It might have have been " " which KMM defaults to. (is there a way to default to showing the memo field instead, if the memo is filled in? I am able to show the memo field by clearing out the space in the payee field, but it's kind of a pain to clear it due to the drop down and extra user logic in order to actually enter the cleared state rather than revert to " " after editing... so sometimes I goof and it doesn't "take".)

ipwizard wrote:That (the red part) is basically true except for the assignment of a category making the transaction manually entered. Also, if a scheduled transaction exists for the given post date but has not yet been entered into the ledger, the user will be asked if he wants to enter and match it.

I'm going to read this again at lunch and digest some more. Double digestion, ha ha!

drewkeller wrote:Now that I'm a bit more familiar, From/To might not actually have been empty. It might have have been " " which KMM defaults to. (is there a way to default to showing the memo field instead, if the memo is filled in?

What? There is no such default of " " inside KMyMoney. Don't know where this comes from. If you refer to the payee field by From/To then you must have a payee with an empty (well better invisible blank) name. Try to get rid of it.

drewkeller wrote:I am able to show the memo field by clearing out the space in the payee field, but it's kind of a pain to clear it due to the drop down and extra user logic in order to actually enter the cleared state rather than revert to " " after editing... so sometimes I goof and it doesn't "take".)

I wonder where this " " entry comes from. We need to get rid of it. :lightbulb:

ipwizard wrote:I wonder where this " " entry comes from. We need to get rid of it. :lightbulb:

I don't know where it came from. I was down to only 4 transactions using this payee (from the payees screen) so it was easy to change them to an actual payee. However, I couldn't delete the " " payee due to this error: "Cannot remove payee that is still referenced to a transaction thrown in mymoneyseqaccessmgr.cpp:228".

So I renamed it to DUMMY PAYEE and skimmed through all my ledgers trying to find it....Nothing. The .kmy file looks like binary, so I exported all my accounts to QIF and performed a "search in files" with Kate, but I couldn't find the payee in them, either.

No big deal. I can live with a dummy payee

I'm using the CVS version because it seems to be properly handling the escrow portion of my mortgage payments (aka the "fees" in the loan account), whereas the stable version was applying the escrow amount to the loan principle (I wish!).

I'll try to import some more QIFs tonight and see how the matching goes on them.

drewkeller wrote:I don't know where it came from. I was down to only 4 transactions using this payee (from the payees screen) so it was easy to change them to an actual payee. However, I couldn't delete the " " payee due to this error: "Cannot remove payee that is still referenced to a transaction thrown in mymoneyseqaccessmgr.cpp:228".

That means that it is still referenced by another item in the file.

drewkeller wrote:So I renamed it to DUMMY PAYEE and skimmed through all my ledgers trying to find it....Nothing. The .kmy file looks like binary, so I exported all my accounts to QIF and performed a "search in files" with Kate, but I couldn't find the payee in them, either.

See http://kmymoney2.sourceforge.net/online ... rmats.html for some explanation on the various file formats. Yours most likely is the GZIP compressed format. See the specific page for instructions on how to make it readable. The search for the reference would be two-fold: First search the payee record by name and then search the reference by the id-value of the payee.

It appears to me that the spacey payee (ID P000002) was originally referenced in a split transaction that I did a match on. I then later changed the payee (ID P000006) but the text for matching still referred to the original payee....(see below)...? I had about 6 transactions that had this same issue. I went through the xml file and replaced the old payee ID with the new one and then I was able to remove the bogus payee from within KMM.

(amounts and bank ids changed)

Code: Select all

 
   
   
     
     
     
<CONTAINER>
 <TRANSACTION postdate="2009-01-21" memo="1" id="" commodity="USD" entrydate="2009-04-25" >
  <SPLITS>
   <SPLIT payee="P000002" reconciledate="" shares="###/100" action="" bankid="2009-01-21-***-1" number="" reconcileflag="0" memo="1" value="###/100" id="S0001" account="A000095" />
  </SPLITS>
  <KEYVALUEPAIRS>
   <PAIR key="Imported" value="true" />
  </KEYVALUEPAIRS>
 </TRANSACTION>
</CONTAINER>
" />
     
     
     
   
   
   
   
   
   
<CONTAINER>
 <TRANSACTION postdate="2009-01-21" memo="1" id="" commodity="USD" entrydate="2009-04-25" >
  <SPLITS>
   <SPLIT payee="P000002" reconciledate="" shares="###/100" action="" bankid="2009-01-21-***-1" number="" reconcileflag="0" memo="1" value="###/100" id="S0001" account="A000095" />
  </SPLITS>
  <KEYVALUEPAIRS>
   <PAIR key="Imported" value="true" />
  </KEYVALUEPAIRS>
 </TRANSACTION>
</CONTAINER>
" />
   
   
   
 


drewkeller wrote:I went through the xml file and replaced the old payee ID with the new one and then I was able to remove the bogus payee from within KMM.

KMyMoney has recently been fixed to avoid that a user can create the scenario you describe. Now you won't be able to delete a payee even if it is only referenced in a matched transaction.

ipwizard wrote:

drewkeller wrote:I went through the xml file and replaced the old payee ID with the new one and then I was able to remove the bogus payee from within KMM.

KMyMoney has recently been fixed to avoid that a user can create the scenario you describe. Now you won't be able to delete a payee even if it is only referenced in a matched transaction.

Well, the problem was that I wanted to delete the payee and couldn't (probably due to the fix you mention). Which is ok... with the fix, the user still has the history to show that a transaction was originally matched to that payee, even if the payee was changed later.

I guess a fully implemented fix would still allow you to delete the payee if you really wanted to. Perhaps give some options when deleting the payee... (or perhaps when changing the payee in a transaction that already references a payee)...
a) delete the payee and substitute the name instead of ID in the notes
b) delete the payee and change notes to the current transaction payee ID or a different payee ID (could get complicated)
c) don't delete the payee
d) show historical references in the payee's transaction list on the payee's page so they can be changed too
e) ...?...

The easy way would to accept the match which will remove the information about the matched transaction from the file (which is OK). It is only kept as long as you want to unmatch, but you cannot do that after you accepted the match.

ipwizard wrote:The easy way would to accept the match which will remove the information about the matched transaction from the file (which is OK). It is only kept as long as you want to unmatch, but you cannot do that after you accepted the match.

The manual doesn't say anything about accepting the match, but sure enough, there's an option to do it. That is definitely easier.

Since you imported the second (credit card) QIF file before you fixed the transaction in the bank account, there was no reference of this transaction to the (KMyMoney) credit card account and thus could not be matched automatically.

Implying that cheque account ofx should be imported _before_ creditcard ofx.

Since I am going to have forgotten this detail in a couple of months time, perhaps the importer should warn "Import Current Accounts before importing Credit Cards" when you go to import a creit card file.