Thanks for account section, but the cause to your problem lies in those 756 entries you found (presumably most of them being of type SPLIT).

4.7.2 is rather old and is superseded by more than a handful of releases already. I doubt we will do anything there.

Since you're at the XML level already, you can try to use a script I provided for the purpose of finding splits causing rounding problems. You can find it at https://cgit.kde.org/kmymoney.git/tree/contrib/getsplitpart.pl

Thomas,  have this kind of issue fixed in subsequent KMM versions?  If so then I will stop wasting anybody's time (including myself), and upgrade KMM even if I need to upgrade the entire OS....

Ouch, I ran the PERL script, and I may be in trouble...  794 entries were found.

transactionId	splitId	shares	amount
T000000000000010067		1053081/100	10530.81
T000000000000010068		2105133/100	21051.33
T000000000000010069		-104649951/125000	-837.199608
T000000000000010070		-26326997859/25000000	-1053.07991436
T000000000000010071		-4837566113/6250000	-774.01057808
T000000000000010072		-41860024047/50000000	-837.20048094
T000000000000010073		-73716015687/100000000	-737.16015687
T000000000000010074		-44018793/40000	-1100.469825
T000000000000010075		-1668079893/800000	-2085.09986625
T000000000000010076		-26195481317/25000000	-1047.81925268
T000000000000010077		-19350236279/25000000	-774.00945116
T000000000000010078		-105308039389/100000000	-1053.08039389
T000000000000010079		-5792011293/25000000	-231.68045172
T000000000000010080		-4631297679/10000000	-463.1297679
T000000000000010081		-16672642953/4000000	-4168.16073825
T000000000000010082		-52628253409/25000000	-2105.13013636
......


What do you advise ?  I think its because I was entering shares purchases like this:

N shares at $/share instead of $ for N shares, which caused the purchase price to have "infinite" number of decimals....

Ouch. I think, the data entry part has been fixed in a recent version. The problem though is in your data. We need to investigate this and figure out how to solve the problem.

I wouldn't mind truncating each erroneous transaction to lets say 4 digits (which was anyways the price precision with that specific investment firm), then deal with the residuals of each investment by manually creating a dummy transaction just to bring the balance to 0 and adjust the selling price accordingly...

Would that be a decent workaround?  Otherwise, I'd put this bug on lower priority because it is not stopping me from working with KMM, its just I have accounts laying around that I do not use anymore and need to uncheck them every time I prepare a new report...

Some information must be truncated (actually rounded), others not. I think, lowering priority and leaving it here is the better approach.

2 pieces of information:

1.  I Upgraded to KMM 5.0.0 and this is not helping, so I think the issue must really be in my dataset not related to KMM itself (or the bug is still there in 5.0.0)

2.  I tried increasing the resolution (number of trailing digits) of ALL shares in these investments, the balance is realy 0.00000000000 when closing the brokerage account so there is NO residuals that I can see...

Changed KMM version in this bug ticket, in KMM > Help > About KMM I see Version 5.0.0 but Linux Mint package reports 5.0.1..........

dpkg -s kmymoney
Package: kmymoney
Status: install ok installed
Priority: optional
Section: kde
Installed-Size: 12337
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Version: 5.0.1-2
Depends: kio, libalkimia5-7 (>= 7.0), libaqbanking35 (>= 5.6.1beta), libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgmp10, libgpgmepp6 (>= 1.10.0), libgwengui-cpp0, libgwengui-qt5-0, libgwenhywfar60 (>= 3.11.6), libical3 (>= 3.0.0), libkchart2 (>= 2.6.0), libkf5activities5 (>= 4.96.0), libkf5akonadicore-bin, libkf5akonadicore5abi1 (>= 4:16.12.3+git20170414), libkf5archive5 (>= 4.96.0), libkf5codecs5 (>= 4.96.0), libkf5completion5 (>= 4.97.0), libkf5configcore5 (>= 4.98.0), libkf5configgui5 (>= 4.97.0), libkf5configwidgets5 (>= 5.23.0), libkf5contacts5 (>= 15.07.90), libkf5coreaddons5 (>= 5.2.0), libkf5holidays5 (>= 15.12.0), libkf5i18n5 (>= 4.97.0), libkf5identitymanagement5abi1 (>= 16.04.3), libkf5itemmodels5 (>= 4.96.0), libkf5itemviews5 (>= 4.96.0), libkf5jobwidgets5 (>= 4.96.0), libkf5kcmutils5 (>= 4.96.0), libkf5kiocore5 (>= 4.96.0), libkf5kiofilewidgets5 (>= 4.96.0), libkf5kiowidgets5 (>= 4.96.0), libkf5notifications5 (>= 4.96.0), libkf5service-bin, libkf5service5 (>= 5.2.0+git20140930), libkf5sonnetui5 (>= 4.96.0), libkf5textwidgets5 (>= 4.96.0), libkf5wallet-bin, libkf5wallet5 (>= 4.96.0), libkf5webkit5 (>= 4.96.0), libkf5widgetsaddons5 (>= 4.96.0), libkf5xmlgui-bin, libkf5xmlgui5 (>= 4.98.0), libofx7, libpython2.7 (>= 2.7), libqt5core5a (>= 5.9.0~beta), libqt5dbus5 (>= 5.0.2), libqt5gui5 (>= 5.8.0), libqt5network5 (>= 5.1.0), libqt5printsupport5 (>= 5.0.2), libqt5quickwidgets5 (>= 5.3.0), libqt5sql5 (>= 5.0.2), libqt5webkit5 (>= 5.6.0~rc), libqt5widgets5 (>= 5.4.0), libqt5xml5 (>= 5.1.0), libstdc++6 (>= 5.2), libaqbanking35-plugins, kmymoney-common (= 5.0.1-2)
Recommends: gnupg-agent, pinentry-qt | pinentry-x11
Suggests: kcalc
Description: personal finance manager for KDE
 KMyMoney is the Personal Finance Manager for KDE. It operates similar to
 MS-Money and Quicken, supports different account types, categorisation of
 expenses, QIF import/export, multiple currencies and initial online banking
 support.
Original-Maintainer: Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
Homepage: https://kmymoney.org/

Hi

I think I am experiencing a similar issue.
In my case, I have been able to close my brokerage account but I can not close the investment account. (https://forum.kde.org/viewtopic.php?f=69&t=164623)

Balance is equal to zero, and no scheduled transaction is related to those accounts.

Ubuntu 18.04
KMM 5.0.1, I also tried KMyMoney-5.0.8-029de47-x86_64.AppImage

Antoine - in order to close the investment account, you must also first close all the stock accounts in it.  Have you done this?

The issue of 5.0.0/5.0.1 was a known labeling issue, and the original issue probably still exists in 5.1.1, until the data itself can be cleaned up.

(In reply to Jack from comment #10)
> Antoine - in order to close the investment account, you must also first
> close all the stock accounts in it.  Have you done this?

Yes and it solved my issue, thank you Jack.
It was not easy for me to guess that I had to close all the stock account in it because some of the stock account are in multiple investment account.
https://forum.kde.org/viewtopic.php?f=69&t=164623

This bug was initially reported by lp.allard.1, I do not know if he solved his issue

> because some of the stock account are in multiple investment account
This cannot be! An account (stock account here) cannot have multiple parent accounts (investment account here) but only one. What you mean is the security in which the account is denominated. That can be used by multiple accounts in parallel. In case an account object is listed as sub-account to two different accounts the consistency check will fail and the user will be informed that something is wrong.

I do understand how a user might think it was the same stock account in multiple investment accounts, since they have the same name - the name of the security.  It will be one of the topics discussed if/when we think about redesigning how KMM handles investments.
For now, the question is whether we can close this bug?

@antoine:  no I have not been yet able to close the brokerage account.

@Thomas & Jack:  what would I need to do from here to solve this issue?

@lp_allard.1  I had a similar issue some time ago, and what I had to do was to find each of those transactions (one at a time) in the ledger and re-save them.  In my case, they were dividend reinvestment transactions, and I simply re-entered the number of shares and total amount of transaction and let it recalculate the price per share.  In the process, it fixed the old rounding issue.
NOTE: if these are old, reconciled transactions, and they do change, you need to be careful about any changes in the balance of those accounts, just to be sure the most recent balance still matches what you expect it to be.

@Jack,  sounds like a lot of work for a bug to begin with.  There are, if I look at the report I posted here in comment 3, 794 entries, so I assume 794 transactions that would have to be one by one manually edited and re-entered "as-is" which is going to take me hours if not days, and may not even solve the issue. 

We have entered our data the same way.  I entered number of shares and the price per share based on total mount and number of shares...

Maybe a lot of work, but I think less than 794, and may be much less if we figure out exactly what happened.  The CSV file output by that perl script has one split from every transaction in the account, not just problem ones.  For example, I assume the first two rows are deposits into the account from your checking account.  These look like they have no problem.

First, I want to confirm that this is the brokerage account with the problem, not the investment account.  Also, are there any currency conversions involved here?  That would certainly complicate matters.

I'm still wondering about something here.  If you entered N shares and price per share, the total price should not use any more decimal places than the price per share.  Was it always a whole number of shares purchased?  Did you ever sell those shares, and if so, did the proceeds go to that same brokerage account or somewhere else?

I'm also curious why the split-id is missing in that listing, but I think I found a bug in the script, which I will discuss with Thomas on the mailing list.  In the meantime, can you answer the additional questions I just asked?

Thanks.

Yes this is in a brokerage account (cash type) and no, there are no currency conversions involved (all CAD) for both the investment and brokerage accounts.

Looking at my investment statements, I know I entered the number of shares manually (all decimals like 0.2866, more on that later) but cannot remember if I entered the price per share as a division of the total amount spent by the number of shares (using the built-in calculator which I very often do), or if I entered the number directly.

Like I said, all numbers are decimals (prices, amount of shares, price/share) because this investment was a employer's sponsored retirement fund, and what they did is more or less perceive an amount (again a decimal like $268.43) on my paycheck then purchase stocks based on a distribution like so:
Stock A: 7.5%
Stock B: 8.0%
Stock C: 15.50%
....
Total:   100.00%

Therefore the amount of shares purchased for each stock varied each time depending on the price of each stock.

I ended up closing this investment so yes I sold all shares of all stocks, and the proceeds went back to the same brokerage account.  Again, not sure if I entered the price per share manually of calculated with the built-in calculator...

Hope this helps!

Using KMM AppImage 5.1-606 I reopened all stock investments in the faulty investment account which used the brokerage account that I couldn't close, changed the display of digits to 12 and fractions of shares to 1000000 and KMM displayed anomalies in the balance of the investment.

Most of them had balances like -0.000005 or 0.000003.  I adjusted the balances to be ZERO then I could close everything.

THis is IMO caused to the fact that my investment firm probably used different digits than the investments were set to in KMM.

I tried with past program versions to display a higher digit count to try to see if there was rounding errors but KMM always displayed zero... This time with AppImage 5.1-606 KMM could somehow recalculate properly.  Code improvements?  For me this issue is resolved.

Great that it got resolved.  Over time, there have been fixes related to rounding issues, so it might have been possible just to edit the transaction and re-enter the same numbers, but it's not worth testing now.  Thanks for following-up.