| Summary: | Share price precision incorrectly limited to 4 decimal places | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | Tony Bloomfield <tonyb.lx> |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugzilla, ostroffjh |
| Priority: | NOR | ||
| Version: | 5.0.4 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Screenshot4.6
Screenshot5.0 KMyMoney file to re-create problem conversionIDR to EURO.png Demo file with price precision set to 10 Dialog where to set the price precision Showing the ledger and the price tool with correct precision |
||
Created attachment 121381 [details]
Screenshot5.0
Created attachment 121382 [details]
KMyMoney file to re-create problem
Note: in KMM4.6, price precision was specified globally via KMyMoney Settings. In 5.0, it is per investment. I note that in the test file I attached, the price precision for the security was reset to 4; this was probably my fault! However, editing the security to change precision to 6 places makes no difference; the price is still rounded to 4 places, and the total value is still wrong. Created attachment 121417 [details] conversionIDR to EURO.png Hello Tony, Same here in KMM openSUSE Leap 15 and in Mageia 6 as well. No matter what I try this cannot be corrected (falls always back to 4 digits). I definitely need and was used to set the precision to at least 9 digits and that has never been a problem in older KMM versions. But I cannot say when this change crept in. The good thing is that the precision settings of 9 or more digits in all previous files/records is maintained. Michael On 09.07.19 11:45, Tony Bloomfield wrote: > https://bugs.kde.org/show_bug.cgi?id=409614 > > --- Comment #4 from Tony Bloomfield <tonyb.lx@ntlworld.com> --- > I note that in the test file I attached, the price precision for the security > was reset to 4; this was probably my fault! > However, editing the security to change precision to 6 places makes no > difference; the price is still rounded to 4 places, and the total value is > still wrong. > I have seen that in version 5.0.4 the function "Outbox" can be activated / deactivated in the settings under Modules. It is a pity that this does not work anymore, but I have to live with it. I have deactivated it in my installation. greetings Udo (In reply to Fabiano Caruana from comment #6) > I have seen that in version 5.0.4 the function "Outbox" can be activated / > deactivated in the settings under Modules. > It is a pity that this does not work anymore, but I have to live with it. > I have deactivated it in my installation. > > greetings > Udo Sorry ... false Bug!!! greetings Udo Created attachment 121427 [details]
Demo file with price precision set to 10
I took the attached demo file and modified the price precision to 10 and don't see any problem. This is with HEAD of the 5.0 branch.
Screenshots following soon.
Created attachment 121428 [details]
Dialog where to set the price precision
Created attachment 121429 [details]
Showing the ledger and the price tool with correct precision
Apologies for not having my system up-to-date; blame it on my unfamiliarity with git. I have now built 5.0.5, and see the following rather odd behaviour. Entering a new transaction with share count and price (6 places) as above, the total amount is calculated as 5000.08; when I <Enter> the transaction, the displayed price changes to 3.146200. However, if I edit the transaction and re-enter the original price, the amount changes to the correct value of 5000.00 and remains so after clicking <Enter>. Very weird! Screenshots available if needed. I have also had cases where editing a transaction and changing one value causes another value to be saved "strangely" but re-editing the transaction and re-entering the original figures work fine. I think that particular issue is not really what this bug was opened about - so I wonder if this is still a problem or can be closed as having been fixed in the meantime. This must have been fixed in the meantime. |
Created attachment 121380 [details] Screenshot4.6 SUMMARY In 5.0, share prices are rounded to a maximum of 4 decimal places. This is a regression from 4.6 (don't know about 4.8). Assume an investment of 5000.00 at a price of 3.146151 = 1589.2435 shares (this can happen with UK unit trusts aka mutual funds). The investemnt is created with a Fraction of 10000 and prices precision of 6 decimal places. Screenshot4.6 shows the transaction entered in 4.6 with a correct total amount of 5000.00. Screenshot5.0 shows the same transaction imported into 5.0 where the price has been rounded to 3.1462, and an attempt to enter a similar transaction where the amount total amount shows as 5000.08 (until you try to edit it when it changes to 5000.07!). There seems to be no way to adjust this down to 5000.00 via fees etc, making it difficult to balance the books. STEPS TO REPRODUCE Use the attached kmy file and try to enter a transaction using the above figures. OBSERVED RESULT As described above EXPECTED RESULT As shown in screenshot4.6. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu Mate19.04 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION The 2 transactions appear in XML as follows: <TRANSACTIONS count="2"> <TRANSACTION commodity="GBP" entrydate="2019-07-01" id="T000000000000000001" postdate="2019-07-01" memo=""> <SPLITS> <SPLIT price="1/1" account="A000002" shares="-5000/1" number="" id="S0001" reconcileflag="0" reconciledate="" action="" bankid="" payee="" memo="This transaction entered in KMM4.6" value="-5000/1"/> <SPLIT price="3146151/1000000" account="A000003" shares="3178487/2000" number="" id="S0002" reconcileflag="0" reconciledate="" action="Buy" bankid="" payee="" memo="This transaction entered in KMM4.6" value="5000/1"/> </SPLITS> </TRANSACTION> <TRANSACTION commodity="GBP" entrydate="2019-07-07" id="T000000000000000002" postdate="2019-07-07" memo=""> <SPLITS> <SPLIT price="1/1" account="A000002" shares="-125002/25" number="" id="S0001" reconcileflag="0" reconciledate="" action="" bankid="" payee="" memo="" value="-125002/25"/> <SPLIT price="15731/5000" account="A000003" shares="3178487/2000" number="" id="S0002" reconcileflag="0" reconciledate="" action="Buy" bankid="" payee="" memo="" value="125002/25"/> </SPLITS> </TRANSACTION> </TRANSACTIONS>