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.
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.
*** This bug has been marked as a duplicate of bug 241322 ***