GNOME Bugzilla – Bug 794755
Commodity Register displays fractional prices
Last modified: 2018-06-30 00:06:07 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
I have the same exact issue after upgrading to 3.0 on Arch Linux - XML or Postgres backends
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.?
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
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.
But goes back to fraction when another split is clicked.
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.
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.
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?
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.
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.
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.
Created attachment 371479 [details] Test file showing fraction display in share prices
Because I prefer the precise rational price, we should probably have an additional column rounded decimal price? Then the user couldactivate the preferrred column.
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.
Just curious if this is a recognized bug and there are plans on fixing. This new behavior is very annoying. Thanks!!!
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...
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.