Created attachment 184733 [details] screenshot SUMMARY Unfortunately, I do not have a scenario to reproduce this issue from scratch. However, the problem is 100% reproducible for some of transactions that I have. But for other transactions the problem never happens. Steps are: 1. Start creating a new transaction. 2. Pickup up a Payee from the drop down list. 3. I am presented with a dialog to select one of the earlier transactions for the Payee as a template. 4. I select a transaction which was a simple charge (not a transfer, not a split, etc). 5. The current transaction is filled, the amount field is correct (from the template) but it is highlighted as having an error. 6. When click the split button I see that there is a split with two identical operations.
Created attachment 184734 [details] screenshot
Created attachment 184735 [details] screenshot
From the database file, here is how the original transaction looks: <TRANSACTION id="T000000000000005610" postdate="2013-09-27" memo="" entrydate="2013-09-30" commodity="UAH"> <SPLITS> <SPLIT id="S0001" payee="P000043" reconciledate="2018-02-15" action="" reconcileflag="2" value="-28/1" shares="-28/1" price="1/1" memo="" account="A000058" number="" bankid=""/> <SPLIT id="S0002" payee="P000043" reconciledate="" action="" reconcileflag="0" value="28/1" shares="28/1" price="1/1" memo="" account="A000105" number="" bankid=""/> </SPLITS> </TRANSACTION> And that's the new transaction (after KMyMoney attempted some corrections while saving the database): <TRANSACTION id="T000000000000036479" postdate="2025-09-05" memo="" entrydate="2025-09-05" commodity="UAH"> <SPLITS> <SPLIT id="S0001" payee="P000043" reconciledate="" action="" reconcileflag="0" value="-28/1" shares="-28/1" price="1/1" memo="" account="A000058" number="" bankid=""/> <SPLIT id="S0002" payee="P000043" reconciledate="" action="" reconcileflag="0" value="0/1" shares="0/1" price="1/1" memo="" account="A000018" number="" bankid=""/> <SPLIT id="S0003" payee="P000043" reconciledate="" action="" reconcileflag="0" value="28/1" shares="28/1" price="1/1" memo="" account="A000105" number="" bankid=""/> </SPLITS> </TRANSACTION> Some details: A000058 is the (asset) account from which I payed originally and where I am entering the new transaction. A000105 is an expense category of the original transaction. A000018 is an expense category which the default category for the payee in question ( P000043). So, for that payee I have the default category and I have this checked: Use the default category for new transactions with this payee. I guess that this can be the "quirk" that explains the difference.
Based on the above I have a scenario now: 1. Create or pick up a payee that has a default category assigned and "Use the default category..." is enabled. 2. Enter a new (simple, non-split) transaction for the payee but use a category that's different from the default category. 3. Start creating another transaction, select the same payee and pick up the previous transaction as a template. Result: Observe the category of the new transaction is populated as a split.
Git commit 02f047cebdba8bf814a8bbbfab86112da67e262e by Thomas Baumgart. Committed on 12/09/2025 at 07:30. Pushed by tbaumgart into branch 'master'. Clear the split model before loading another transaction When using the autofill transaction feature together with the default category assignment and a transaction was selected from the list of previous transactions, the default category was added as an additional split. This change prevents that additional split to be left over. FIXED-IN: 5.2.2 M +4 -0 kmymoney/views/newtransactioneditor.cpp https://invent.kde.org/office/kmymoney/-/commit/02f047cebdba8bf814a8bbbfab86112da67e262e
Git commit 43e0ed60a8bc3fa646e2eff203d0b8b25f9945ba by Thomas Baumgart. Committed on 12/09/2025 at 07:43. Pushed by tbaumgart into branch '5.2'. Clear the split model before loading another transaction When using the autofill transaction feature together with the default category assignment and a transaction was selected from the list of previous transactions, the default category was added as an additional split. This change prevents that additional split to be left over. FIXED-IN: 5.2.2 (cherry picked from commit 02f047cebdba8bf814a8bbbfab86112da67e262e) M +4 -0 kmymoney/views/newtransactioneditor.cpp https://invent.kde.org/office/kmymoney/-/commit/43e0ed60a8bc3fa646e2eff203d0b8b25f9945ba