Summary: | Payee automatism gives strange results (Part 2) | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | andreas.grupe |
Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED DUPLICATE | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
andreas.grupe
2010-07-05 17:46:40 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. *** This bug has been marked as a duplicate of bug 241322 *** |