| Summary: | creating transaction using older one as template creates a split if payee has different default category | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | Andriy Gapon <avg> |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 5.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| Latest Commit: | https://invent.kde.org/office/kmymoney/-/commit/43e0ed60a8bc3fa646e2eff203d0b8b25f9945ba | Version Fixed/Implemented In: | 5.2.2 |
| Sentry Crash Report: | |||
| Attachments: |
screenshot
screenshot screenshot |
||
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 |
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.