SUMMARY We assume a fraction of 100 for accounts created through "New account" wizard. The ledger view then uses said fraction to display a sum if more than 1 row is selected. If any of the securities are traded with a fraction > 100, the calculated sum will be off. STEPS TO REPRODUCE 1. Add securities with fraction > 100 to a brokerage account 2. Add some transactions 3. Select more than 1 transaction OBSERVED RESULT The sum is rounded to 2 decimal places and is inaccurate. EXPECTED RESULT The sum should not be rounded up and instead displayed using a all the decimal places required.
Git commit c37191ada147cf18f1c74dab70c02a425b67104a by Dawid Wróbel. Committed on 25/04/2020 at 22:01. Pushed by wrobelda into branch 'master'. Display transactions sum using all decimal places For a sum of multiple rows selected in the global ledger view, use the automatically determined minimum required precision to avoid truncating the value M +1 -1 kmymoney/views/kgloballedgerview.cpp https://commits.kde.org/kmymoney/c37191ada147cf18f1c74dab70c02a425b67104a
Maybe I don't understand something here, but for an investment transaction, the split for the brokerage account is always in the currency of the brokerage account, no matter how many decimal places are used for the number of shares transacted. At least for every investment account I have had, the amount of money used for any transaction (buy, sell, dividend) is always stated in whole cents (2 decimal places for $US) no matter the the fraction used for number of shares and price per share. I'd really like to see an example that demonstrates the problem you see.
Jack, this is not about the value – if you select more than one transaction, the sum displayed is of the quantity of the shares. Hope that explains it.
Is this in the investment account or the brokerage account? Comment 1 starts with adding securities to a brokerage account, which doesn't actually make sense. In the investment account, I don't think it makes any sense to show a sum of anything, unless the selected transactions are all for the same security. In that case, why not use use precision of the security, instead of just figuring what the transactions need. If the transactions are for different securities, I would prefer not to show any total since it would be like adding the amounts in different currencies. With currencies, at least you could show the total after conversion to the base currency of the account.
Jack, yes, point 1. was supposed to say "investment account", not "brokerage". > In the investment account, I don't think it makes any sense to show a sum of anything This functionality was already in place and I find it useful. > unless the selected transactions are all for the same security. I think we can safely assume the users are smart enough to understand which securities they select and what does the sum mean in this case. Besides, I don't think you're right – I myself specifically had to sum the shares of different securities after my brokerage automatically liquidated B class of shares and repurchased C class. Either way, it's a different issue, unrelated to this bug fix. > In that case, why not use use precision of the security, instead of just figuring what the transactions need. We don't need to figure out the precision at all when summing the values. The precision only matters when converting the floating point value to a string for displaying and the MyMoneyMoney::formatMoney() function can handle that automatically – which my code change took advantage of.
Git commit 7d860a6b0f17b7903bbe14ce93f798a25067f150 by Thomas Baumgart. Committed on 01/05/2020 at 05:40. Pushed by tbaumgart into branch '5.0'. Display transactions sum using all decimal places For a sum of multiple rows selected in the global ledger view, use the automatically determined minimum required precision to avoid truncating the value FIXED-IN: 5.0.9 (cherry picked from commit c37191ada147cf18f1c74dab70c02a425b67104a) M +1 -1 kmymoney/views/kgloballedgerview.cpp https://commits.kde.org/kmymoney/7d860a6b0f17b7903bbe14ce93f798a25067f150