| Summary: | Payee automatism gives strange results (Part 1) | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | andreas.grupe |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED WAITINGFORINFO | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
andreas.grupe
2010-07-05 17:39:29 UTC
What version of KMyMoney are you using? Where did you install it from? I'm using 3.98.1 and downloaded it from http://kmymoney2.sourceforge.net/index2.html Sorry that I missed that. Andreas What are the option settings on PAYPAL on the "Matching" tab of the payee? Does the transaction of PAYSAGE show that name or is it attached to PAYPAL? The "Kirsten/KIRSTE" case is by design. This is to allow matching the payee name with any addition provided by some stores. This might not happen with HBCI but is common using QIF or OFX. You can avoid it by adding "^KIRSTE$" to the list of matching names. The options for Paypal are "Nach Zahlungsempfänger zuordnen" (the middle one, don't know the english text) as are all payees automatically assigned to. The transaction PAYSAGE is treated as if it was a PAYPAL transaction. The name shown was correct but the category assigned was wrong. Paypal is assigned to transactions comming from a (manual) bank account (as Paypal does not provide an online account) matching my normal online bank account. Paysage is a payment from a customer comming to my normal online bank account. If it's still unclear I can only give more details in German ;-( To touch every single payee to avoid the Kirsten/Kirste case is not possible. I would have to touch hundreds of payees. And all new payees every day (between 10 and 20 per day) , too. And there are other cases like Kaufhof (expense category) is treated the same as Hof (income) and so on and so on. I'm working with HBCI. Hope that helps. I'm happy to provide more details. The only thing I'd like to have is a simple way to stop the automatism to assign transactions to customers. Thanks for your help. Andreas Am 02.08.2010 10:42, schrieb Thomas Baumgart: > https://bugs.kde.org/show_bug.cgi?id=243669 > > > > > > --- Comment #3 from Thomas Baumgart <ipwizard users sourceforge net> 2010-08-02 10:42:37 --- > What are the option settings on PAYPAL on the "Matching" tab of the payee? > > Does the transaction of PAYSAGE show that name or is it attached to PAYPAL? > > The "Kirsten/KIRSTE" case is by design. This is to allow matching the payee > name with any addition provided by some stores. This might not happen with HBCI > but is common using QIF or OFX. You can avoid it by adding "^KIRSTE$" to the > list of matching names. > > Sorry for writing a 2nd mail. I recognised an other case. It happens that customer names are misinterpreted and they are displayed wrongly, too (like Meyer is correkt but Meiner is displayed). And often the payee names are not recognized at all. Even if the text is more or less the same as with other transactions where the names are read correctly. I'll post you an example for the first case here, as soon as it happens again. Cheers Andreas Am 02.08.2010 10:42, schrieb Thomas Baumgart: > https://bugs.kde.org/show_bug.cgi?id=243669 > > > > > > --- Comment #3 from Thomas Baumgart <ipwizard users sourceforge net> 2010-08-02 10:42:37 --- > What are the option settings on PAYPAL on the "Matching" tab of the payee? > > Does the transaction of PAYSAGE show that name or is it attached to PAYPAL? > > The "Kirsten/KIRSTE" case is by design. This is to allow matching the payee > name with any addition provided by some stores. This might not happen with HBCI > but is common using QIF or OFX. You can avoid it by adding "^KIRSTE$" to the > list of matching names. > > Did it happen again in the meantime? Changing state due to missing feedback |