[Kmymoney-devel] [Bug 272712] Option to automatically place transactions in categories by fields other than Payee

David Alston david.alston at gmail.com
Thu Jan 5 21:37:19 UTC 2012


https://bugs.kde.org/show_bug.cgi?id=272712





--- Comment #15 from David Alston <david alston gmail com>  2012-01-05 21:37:17 ---
> The only issue is that if an import fails
> to match because the bank has changed again, redo the import telling KMM to use
> a different field to match the Payee.

This would work if I was only importing one transaction.  In the same monthly
statement some stores have strings useful for matching Payee's in the Payee
field while other stores have their useful string in the "Memo" field.


> One possible enhancement request here is a setting for KMM to look in more than
> one field in an import (payee, memo, description) to match the payee, and only
> create a new payee if none of them match.  If this sounds useful, I'll be glad
> to create a new wishlist entry for it.

We do seem to be typing in circles :^)  I don't really mind what the Payee
field is as long as the transaction is categorized correctly.  If we need to,
as you suggest, adjust what kmymoney considers the Payee field to be on a
per-transaction basis then the "matching strings" functionality of the Payees
section would be able to apply the categories to my liking.

Another way to approach it would be to tie the category to the transaction (or
it's splits) instead.  This would give the auto-categorizor much more
flexability since it wouldn't necessarily be tied to the "Payee" at all.  The
auto-categorizor would watch during the imports for anything that matches its
rules (eg. "Payee == Aldi" or "Memo == Kroger" or "Memo == Kroger && Debit >
10.00") and apply the appropriate category.  Using this approach we could leave
the data as close to the format of the original import as possible since we
wouldn't have to figure out rules for "The payee is now in the memo field" or
"the Payee is now in the Payee field."

I'm happy with whichever approach fulfills the communities general consensus. 
I'm still very impressed with the rich feature set that kmymoney already has. 
It really is an exceptional product.


If this wishlist request is too confusing to be useful then it probably does
need a new bug number and a new description.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the KMyMoney-devel mailing list