I recently upgraded kmymoney from 5.1.3 to 5.2.0, and am experiencing a couple of issues.
The biggest is a huge number of Consistency Check errors, showing up whenever I try to save the database, or via Tools->Consistency Check:
* Problems with transactions
* Split S0002 in transaction 'T000000000000000250' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000000251' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000000252' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000000344' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000000345' contains different signs for shares and value. Please fix manually.
...
* Split S0002 in transaction 'T000000000000015645' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000015720' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000015721' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000015722' contains different signs for shares and value. Please fix manually.
* Split S0002 in transaction 'T000000000000015723' contains different signs for shares and value. Please fix manually.
Finished: 0 problems corrected. 966 problems still present.
There are almost 1000 of these, so obviously I’m not going to be fixing them manually.
Looking at my database XML, I was able to find a few of these and locate them in the kmm ledger. It looks like they are investment “Reinvest Dividend” transactions, where the investment “price entry” setting is “Total for all shares”. I think all of these transactions were downloaded/imported. In the kmm ledger, the value column is indeed negative.
I looked at a backup copy of my database from before the upgrade, and installed kmm 5.1 (via flatpak) and these transactions look the same there - they have negative values, but the Consistency Check there doesn’t complain about anything.
So is this something that older versions tolerated? Any thoughts on fixing this?
Replying to myself here. I’ve been doing some xml reverse engineering trying to figure out the fix to this.
A simple regex search in the kmymoney xml file can find all of the transactions that kmm is complaining about. Each one of these investment transactions is actually a split transaction internally, with the data in 2 splits. It looks like some simple changes (sign changes) have to be made to each line.
Having to update 2 lines in the transaction (not just the one the regex matched), I don’t see how a simple regex search & replace can handle this. I think it’s going to involve some deeper hackery to fix (python probably)
Are you in a position to post one transaction here, so that others might help?
Yes, sorry I didn’t update this earlier. Here is an example transaction:
<TRANSACTION id="T000000000000015722" postdate="2025-05-30" memo="Dividends" entrydate="2025-06-04" commodity="USD">
<SPLITS>
<SPLIT id="S0001" payee="" reconciledate="" action="" reconcileflag="0" value="1759/20" shares="1759/20" price="1/1" memo="Dividends" account="A000049" number="" bankid=""/>
<SPLIT id="S0002" payee="" reconciledate="" action="Reinvest" reconcileflag="0" value="-1759/20" shares="4557/500" price="193/20" memo="Dividends" account="A000246" number="" bankid="***"/>
</SPLITS>
</TRANSACTION>
The problem is that, in split S0002, “value” is negative but “shares” is positive. After updating one of these in Kmm and looking at the fixed XML, it appears the fix is to make both value and shares negative in split S0001 and make value positive in split S0002.
Since every one of these failing transactions is split in this same order in the XML, I was able to write a find & replace regex that spans both lines, using capture groups, that fixed it, in kwrite:
find: <SPLIT id="S0001"(.*) value="([^"]*)" shares="([^"]*)"(.*$\n\s*)<SPLIT id="S0002" (.*) value="-([^"]*)" shares="(\d)
replace: <SPLIT id="S0001"\1 value="-\2" shares="-\3"\4<SPLIT id="S0002" \5 value="\6" shares="\7
You’re right about the solution, the first split references the income category and the second the account it was paid to. So the signs must be changed as you say.
It is important to keep the sum of the value entries of all splits to be zero, so in a transaction with two splits, one is positive and the other negative. Shares and value entries of a split must have the same sign.
Do you happen to know where these transactions came from? Did you enter them manually or were they imported? In the latter case, which method?
Thank you - I was still a little concerned that this fix may cause some problem I wouldn’t catch until later, so your confirmation is a relief.
I think all of these are reinvestment transactions that were downloaded from TIAA-CREF. They were downloaded using the “Update Account” function inside kmymoney, not by importing an externally downloaded file into kmm.
I am concerned about updating these accounts going forward. I will probably need to start downloading a transaction file, run a script to fix it, then import it into kmm.
You don’t need to be concerned. There are only two possible cases:
- You do an update and everything is fine or
- You do an update and the problem is still around.
In case 1. we must have fixed the problem, in case 2. that is still ahead of us and you can support us in providing more detailed information. Also, if you don’t save the data after the import you can redo it over and over again. Which protocol (OFX, KBanking, …) did you use when mapping this account?
@ipwizard - it’s been years since I set up these accounts (there are several involved) and I don’t remember any of the details now. In one of the account’s Online settings, there is an “OFX details” tab, so I guess the answer to that question is OFX protocol.
@Alight_Motion - Thank you for the clarification. This matches my situation. I set up most of my investments with the Price Entry option set to “Total for all shares”. Otherwise, round off errors throw off the balance in the matching brokerage account.
I’ve tried an import into these accounts, and the negative values on reinvestment transactions are still being imported.
I am no longer able to do direct imports from kmymoney in these accounts - I am going to play with that later and maybe open another thread here.
I can download a .qfx file with transactions and import that into kmm, and the imported reinvestments have negative totals and are outlined in red in kmm’s ledger. Below is a sample reinvestment transaction from a .qfx download (I think this is all of it, those are not the most straightforward files to make sense of):
<REINVEST><INVTRAN><FITID>***<DTTRADE>20250630160000.000[-4:EDT]<DTSETTLE>20250630160000.000[-4:EDT]<MEMO>Dividends</INVTRAN><SECID><UNIQUEID>***<UNIQUEIDTYPE>CUSIP</SECID><INCOMETYPE>DIV<TOTAL>-86.34<SUBACCTSEC>CASH<UNITS>8.9194<UNITPRICE>9.68</REINVEST>
The of -86.34 is the problem. Now that I know this is happening, the fix is pretty simple in the kmm ledger. If the investment “Price entry” setting is “price per share”, all I have to do is edit one of these and then press ENTER to save it, and the total is saved with the correct sign.
A few things happened:
- The importer (actually statement reader which is used by all importers) deals with this scenario and imports the data correctly
- The consistency check has been updated to fix this specific issue
- The central engine code does not accept splits where shares and value have different signs
#1 and #2. will make it into version 5.2.1
#3 is kept for 5.3+ because otherwise files containing the problem cannot be loaded.