Bug 403249 - When buying / selling shares for an investment, the value is rounded to two decimal places
Summary: When buying / selling shares for an investment, the value is rounded to two d...
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: git (master)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-01-15 21:36 UTC by Ian Neal
Modified: 2021-12-28 00:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.3
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Neal 2019-01-15 21:36:56 UTC
SUMMARY
When buying / selling shares for an investment, the value is rounded to two decimal places

STEPS TO REPRODUCE
1. Create a new bond, have fraction set to 1/1000000 and price precision set to 4 or higher.
2. Buy some shares, say 1.123456 at price/share of 1
3. Look at the value associated with buy.

OBSERVED RESULT
Value shows as 1.120000

EXPECTED RESULT
Value shows as 1.123456

SOFTWARE/OS VERSIONS
Windows: 
MacOS: 
Linux/KDE Plasma: Fedora 28
(available in About System)
KDE Plasma Version: 5.13.5-1
KDE Frameworks Version: 5.53.0
Qt Version: 5.11.1

ADDITIONAL INFORMATION
If you re-edit the transaction then the value gets corrected to 1.123456
This used to be an issue in 4.x and got fixed around 2016 to 2017.
Comment 1 Ian Neal 2019-01-15 21:55:50 UTC
The currency I used for the investments is Palladium as it gives smallest money/cash unit of 0.000001
Comment 2 Thomas Baumgart 2019-01-19 13:10:36 UTC
This must be a side effect/consequene of commit https://cgit.kde.org/kmymoney.git/commit/?id=c6e31c96a03ad5a7ec5e3695bbfa8336181ab81c which solves a bunch of other issues. I don't want to break those by reverting the patch, so it needs further analysis.
Comment 3 Thomas Baumgart 2019-01-19 15:31:19 UTC
Git commit e38492cbc059796addb5a62861e75b851b2428e0 by Thomas Baumgart.
Committed on 19/01/2019 at 15:27.
Pushed by tbaumgart into branch '5.0'.

Fix security creation logic

In case no smallest account fraction is provided in the ctor of a
MyMoneySecurity object it should use the same value as provided for the
smallest cash fraction. Providing a default value of 100 destroys this
logic. This forced Palladium to have values always rounded to two
decimals.

In case the user has such a security on file there is no other way as
manually fixing it by copying the value from the SCF attribute to the
SAF attribute in the XML file and the value in the smallestCashFraction
column to the smallestAccountFraction column in the database.

M  +1    -1    kmymoney/mymoney/mymoneysecurity.h

https://commits.kde.org/kmymoney/e38492cbc059796addb5a62861e75b851b2428e0
Comment 4 Thomas Baumgart 2019-01-19 15:31:19 UTC
Git commit bd103f87388b56c873210266887272d490b22ad2 by Thomas Baumgart.
Committed on 19/01/2019 at 15:32.
Pushed by tbaumgart into branch '5.0'.

Setup the transaction commodity based on the trading currency

For new investment transactions the commodity was always set to the
baseCurrency instead of the securities trading currency. This usually
caused the values to be rounded to two decimals (smallest account
fraction of the base currency).

This change fixes the problem by not looking at the empty original
transaction in this case.
FIXED-IN: 5.0.3

M  +7    -4    kmymoney/dialogs/investtransactioneditor.cpp

https://commits.kde.org/kmymoney/bd103f87388b56c873210266887272d490b22ad2
Comment 5 Ian Neal 2019-01-20 14:41:28 UTC
Pulled latest git master and can verify this has fixed my issue.
Comment 6 Jack 2019-01-26 23:49:02 UTC
just correcting final status, but thanks for confirming that the fix works.