I have several categories with automatic tax assignment. Also, the automatic assignment of new transactions from an online-banking-account to the categories is active. This assignment to categories works fine, but for the amount of the split transactions the values of the "remembered" transaction is used. Reproducible: Always Steps to Reproduce: For example: On my online bank account there is a "Telecash" income. I assign this to the categorie "Erlöse 19% USt" (German SKR03). This categories automatically splits the transaction to this categorie and the account "Umsatzsteuer 19%". So, 119€ on my bank account is splitted into 100€ to "Erlöse 19%" and 19€ to "Umsatzsteuer 19%". But with the next online update of my bank account, there is for example a new "Telecash" income of 200€. Kmymoney recognize, that this is a "Erlös 19% USt.", so automatically assigns the transaction to "Erlöse 19%" and "Umsatzsteuer 19%", but the amount of the transactions is again 100€ and 19€, so there is a missing amount 81€. kmymoney warns about this, but there is no easy way to correct this. In fact, I have to delete the splitted transaction, double-confirm this and reenter the "Erlöse 19%" categorie. The same problem exists with expenses of my online bank account. If they are automatically splitted for taxes, kmymoney messes with the amounts of the splitted transactions. Expected Results: Of course, the nicest solution would be that kmymoney would automatically recalculate the amounts of a splitted transaction in case it is an "automatic" split (taxes). I choosed serverity as "major", because the major feature "transaction matching" is broken when using it in combination with the major feature "VAT support".
I'm not sure how the VAT support is supposed to work (I'm in the US) but I believe this is just an unintended consequence of the way Payee matching works on import. If an imported transaction matches a Payee, then KMM uses the most recent already existing transaction as the starting point for the imported transaction. I have a similar problem, but with a credit card. For example, most of the time I use the credit card at StoreA, I just buy food, so it is a plain transaction (not split) with category Food. One day, I need to split a transaction at that store (part Food and part Liquor, for example.) The next time I import a credit card transaction for that store, it will be imported as a split transaction for those two categories. The amount of each split will be for the amounts from the old transaction and the total will be the amount from the newly imported transaction, so the total will not match. However, when this happens, I only needed to delete the splits, and put the correct category on the transaction. You should also be able to edit the transaction, delete the splits, and create them as you want them. I don't think you should need to totally delete the transaction. Someone else will have to answer whether VAT support is supposed to have any different effect on this Payee matching process.
Not really sure. It is that way for a long time and it annoys me as well when dealing with online transaction download and VAT assignments.
Could this patch https://git.reviewboard.kde.org/r/113011/ have solved this issue? Or that just handles creating VAT splits for imported new transactions and not matching already existing transactions. It would be nice tf you could test your scenario using a build from git master or attach some test files so I could do it.
Could you check my previous comment?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!