After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794755 - Commodity Register displays fractional prices
Commodity Register displays fractional prices
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
3.0
Other Windows
: Normal normal
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
Depends on:
Blocks:
 
 
Reported: 2018-03-28 08:06 UTC by Alen Siljak
Modified: 2018-06-30 00:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test file showing fraction display in share prices (1.81 KB, application/x-gnucash)
2018-04-28 00:44 UTC, lj308
Details

Description Alen Siljak 2018-03-28 08:06:24 UTC
The register in 2.7.8 displays fractional price for commodity accounts. 
This is a bit confusing to look at as my brain is too slow process the division of i.e. 1250 with 2449.

See https://imgur.com/SA3Kkbh
Comment 1 rollenwiese 2018-04-03 19:25:32 UTC
I have the same exact issue after upgrading to 3.0 on

Arch Linux
- XML or Postgres backends
Comment 2 Alen Siljak 2018-04-04 12:55:18 UTC
Hmm, this is not always the case. I have some records that are displayed as expected while others are displayed in fractions.
Any hints as to where I should look? Where is the register price displayed from? Is it calculated or read from the price table, recalculated, etc.?
Comment 3 John Ralls 2018-04-04 13:43:11 UTC
I think the logic there displays a decimal if it can make one without rounding and a fraction otherwise. I'd start with gnucash/gnome/dialog-price-edit.c and then libgnucash/engine/gnc-pricedb.c
Comment 4 Alen Siljak 2018-04-04 15:05:22 UTC
Interesting. The price in the register row is displayed as 3791/36209.

Once the row has a focus, set by clicking on it (whether it is the transaction row or a split row), the price displayed in this row displays changes to decimal format - i.e. 1.1047.
Comment 5 Chris Good 2018-04-04 23:04:07 UTC
But goes back to fraction when another split is clicked.
Comment 6 lj308 2018-04-07 21:31:34 UTC
In case it might help developers, when the fractions are displayed in the register, a number of these messages are logged:

  WARN <qof> [gnc_numeric_to_decimal()] Rounding required when 'never round' specified.

I also notice that in some cases when the transaction is selected and the price is displayed as a decimal, the decimal value differs from that shown by Gnucash-2,6,x. For example: Gnucash-2.6.x shows the correct share price of 14.42; Gnucash-3.0 shows 14 + 39902 / 95007 when the row is not selected, and when the row is selected it shows 14.41999 which is incorrect.
Comment 7 David Carlson 2018-04-08 04:30:39 UTC
Actually, 39902/95007 is .41999.  If that value came from a purchase or sale transaction it is probably the value required to make the total dollar amount and the number of shares both correct.  That is quite often the case on brokerage statements, where they always round prices to two decimal places.  Recent Releases before 3.0 also round decimal prices to two decimal places unless the user has changed the default, but earlier releases showed the fractional numbers.
Comment 8 Chris Good 2018-04-22 01:40:21 UTC
Is this the same problem that now causes stocks for which a buy has been entered in GnuCash 3.0, to show a Price (Unit) with 6 decimals in the Advanced Portfolio Report, while all my other stocks show only 2 decimals?
Comment 9 Chris Good 2018-04-22 05:56:15 UTC
I see from testing in 2.6.19 (Linux) that the (unit) price previously showed between 2 and 6 decimals if it came from a transaction, rather than the price database, so my previous comment is NOT a change in behaviour for 3.0.
However, the Advanced Portfolio Report now shows (unit) prices like $29 + 58581/84250 when the price comes from a transaction but presumably this will be fixed when this bug is fixed.
Comment 10 Geert Janssens 2018-04-27 12:15:23 UTC
I can't reproduce this with gnucash built from the current maint branch (3.0-105-gd0fca7794).

I have tried creating commodity related transactions or transactions involving multiple currencies. In all cases the amounts show normally. Perhaps I'm doing it wrong though as I'm not using commodities myself.

Can someone post a sample file to illustrate this ? It can be a file with only one transaction showing the isse.
Comment 11 lj308 2018-04-28 00:42:13 UTC
To reproduce, you need to (1) use a mutual fund that allows fractions of shares, not a stock that is traded in whole shares only, and (2) enter the total BUY amount and the number of shares, and let GnuCash calculate the share price.

While (2) might seem odd - don't we know the share price? - I find that I have to do it this way to get my records to match the brokerage. The numbers that must match are the number of shares I own, and the total price I paid.

I will attach a file fractiontest.gnucash which is a simple test file with 3 transactions, 2 of which have the fraction display issue with GnuCash-3.0.
Comment 12 lj308 2018-04-28 00:44:26 UTC
Created attachment 371479 [details]
Test file showing fraction display in share prices
Comment 13 Frank H. Ellenberger 2018-05-01 19:41:56 UTC
Because I prefer the precise rational price, we should probably have an additional column rounded decimal price? Then the user couldactivate the preferrred column.
Comment 14 Alen Siljak 2018-05-09 07:32:01 UTC
The instruction in comment 11 (https://bugzilla.gnome.org/show_bug.cgi?id=794755#c11) is not entirely correct. One does not need to enter the total amount. I never do that, for example. However, I do not (yet) know how exactly to reproduce as it is not bothering me too much.
I normally enter just the number of shares and the price, as reported by the brokerage service.
Comment 15 chris 2018-06-25 17:21:51 UTC
Just curious if this is a recognized bug and there are plans on fixing.  This new behavior is very annoying.  Thanks!!!
Comment 16 Geert Janssens 2018-06-25 17:40:05 UTC
Yes, it's recognized as a bug and will be fixed eventually. There are still more urgent issues to solve which is why it didn't happen yet.

Patches/PR's are welcome of course...
Comment 17 John Ralls 2018-06-30 00:06:07 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=794755. Please continue processing the bug there and please update any external references or bookmarks.