Bug 243671

Summary: Payee automatism gives strange results (Part 2)
Product: [Applications] kmymoney Reporter: andreas.grupe
Component: generalAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: RESOLVED DUPLICATE    
Severity: wishlist    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description andreas.grupe 2010-07-05 17:46:40 UTC 
Version:           unspecified (using KDE 4.4.3) 
OS:                Linux

This is part 2 of an unexpected behavior of the automatic payee detection. It's results are different to the first bug report but someone might put both together as they are related to the same problem.

Part 2: If a payee is already existent and a VAT category was assigned to the first of his transactions, a newly payment of this person results in an incorrect split transaction

Reproducible: Always

Steps to Reproduce:
I received a payment about 8.24 Euros
The customer had payed before and his payments are assigned to a VAT split category



Actual Results:  
5.43 Euros income with VAT
1.03 Euros VAT
1.78 Euros unassigned

Expected Results:  
6.92 Euros income with VAT
1.32 Euros VAT

Just don't do the auto assignment of payees would stop the problem (but not fix the problem). It wouzld be good to have an option to turn this off.
Comment 1 Thomas Baumgart 2010-08-02 11:24:37 UTC 
From the source of the statement reader:

      // Note, this logic is lifted from KLedgerView::slotPayeeChanged(),
      // however this case is more complicated, because we have an amount and
      // a memo.  We just don't have the other side of the transaction.
      //
      // We'll search for the most recent transaction in this account with
      // this payee.  If this reference transaction is a simple 2-split
      // transaction, it's simple.  If it's a complex split, and the amounts
      // are different, we have a problem.  Somehow we have to balance the
      // transaction.  For now, we'll leave it unbalanced, and let the user
      // handle it.

The VAT stuff falls under the part of the "complex split" transaction. A future version should handle this case more gracefully (e.g. in case of a VAT split recalculate it like we do in the transaction editor).

I converted this one into a wishlist item so that we don't forget about it.
Comment 2 Thomas Baumgart 2010-08-02 11:28:20 UTC 

*** This bug has been marked as a duplicate of bug 241322 ***