Bug 409614 - Share price precision incorrectly limited to 4 decimal places
Summary: Share price precision incorrectly limited to 4 decimal places
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 5.0.4
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-08 09:33 UTC by Tony Bloomfield
Modified: 2022-03-13 07:06 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot4.6 (113.37 KB, image/png)
2019-07-08 09:33 UTC, Tony Bloomfield
Details
Screenshot5.0 (167.82 KB, image/png)
2019-07-08 09:33 UTC, Tony Bloomfield
Details
KMyMoney file to re-create problem (24.15 KB, application/x-kmymoney)
2019-07-08 09:34 UTC, Tony Bloomfield
Details
conversionIDR to EURO.png (28.89 KB, image/png)
2019-07-09 11:37 UTC, Michael Berger
Details
Demo file with price precision set to 10 (4.37 KB, application/gzip)
2019-07-09 15:54 UTC, Thomas Baumgart
Details
Dialog where to set the price precision (48.74 KB, image/png)
2019-07-09 15:54 UTC, Thomas Baumgart
Details
Showing the ledger and the price tool with correct precision (26.97 KB, image/png)
2019-07-09 15:55 UTC, Thomas Baumgart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Bloomfield 2019-07-08 09:33:22 UTC
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>
Comment 1 Tony Bloomfield 2019-07-08 09:33:58 UTC
Created attachment 121381 [details]
Screenshot5.0
Comment 2 Tony Bloomfield 2019-07-08 09:34:28 UTC
Created attachment 121382 [details]
KMyMoney file to re-create problem
Comment 3 Tony Bloomfield 2019-07-08 09:36:48 UTC
Note: in KMM4.6, price precision was specified globally via KMyMoney Settings. In 5.0, it is per investment.
Comment 4 Tony Bloomfield 2019-07-09 09:45:16 UTC
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.
Comment 5 Michael Berger 2019-07-09 11:37:21 UTC
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.
>
Comment 6 Fabiano Caruana 2019-07-09 11:59:24 UTC
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
Comment 7 Fabiano Caruana 2019-07-09 12:02:40 UTC
(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
Comment 8 Thomas Baumgart 2019-07-09 15:54:21 UTC
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.
Comment 9 Thomas Baumgart 2019-07-09 15:54:49 UTC
Created attachment 121428 [details]
Dialog where to set the price precision
Comment 10 Thomas Baumgart 2019-07-09 15:55:26 UTC
Created attachment 121429 [details]
Showing the ledger and the price tool with correct precision
Comment 11 Tony Bloomfield 2019-07-20 09:38:44 UTC
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.
Comment 12 Jack 2021-02-17 00:21:33 UTC
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.
Comment 13 Thomas Baumgart 2022-03-13 07:06:49 UTC
This must have been fixed in the meantime.