Created attachment 373891 [details] gnucash 4.2 report exchange rate display Hi team, I have a multi-currency setup so when I run reports (Balance Sheet, Profit and Loss, Trial Balance) I click on options -> commodities -> and tick "Show Foreign Currencies" and "Show Exchange Rates". Back in v3 of gnucash, these would display with 2 decimal places (the same number of decimal places as Edit -> Preferences -> Numbers -> Decimal Places). Now in v4.2 of gnucash, these Exchange Rates display with 4 decimal places with the last two places zero so the number displayed is still effectively rounded to 2 decimal places. But the Price Database from where these exchange rates are extracted holds them to 6 decimal places and it does seem as though the currency conversions in the report line items do honour the 6 decimal places exchange rates. So you could argue: -1- listing an exchange rate of $1.6300 instead of the rate actually used of 1.627650 is misleading or -2- wouldn't it be helpful to have a separate setting for number of decimal places to display exchange rates (defaulting to 4 as seems to be hinted at in the change from v3 to v4 of gnucash). [I know those big City types who boast of making their living on the fifth decimal place would probably appreciate it]. Anyway, what do you think? Regards Phil
Created attachment 373892 [details] gnucash 3.11 report exchange rate display gnucash 3.11 for comparison
That's a matter of some controversy, but first a couple of corrections: First, the decimal places setting in Preferences>General>Numbers is for the automatic decimal point feature, the check box for which is immediately above it. When enabled that emulates certain ancient adding machines that assumed the last n digits (usually 2) were to the right of the decimal. It has nothing to do with display. Second, numbers in GnuCash aren't decimals, they're rationals: Fractions with an arbitrary denominator. For prices and exchange rates in particular that enables a level of accuracy not possible with decimals because decimals cannot represent many fractional values exactly. There is a preference: Force prices to decimal. It's located just above the auto-decimal one on the General tab. If you turn it off you'll get an exact decimal if that's possible and an integer plus a fraction, e.g. 47 + 11/67, if it isn't. There's no preference for changing the number of decimals if force prices to decimal is set, nor are we likely to introduce one. The number of decimals used is 1/100 the smallest currency unit for the currency in use for the price display. That is indeed 4 places for most currencies, but for those that don't have a fractional unit like the Japanese Yen it will be 2 decimal places.
Thanks, yet again, for your kind and patient explanation, it is much appreciated, especially being attended to on a weekend. "The number of decimals used is 1/100 the smallest currency unit for the currency in use for the price display. That is indeed 4 places for most currencies" which would be great if the last two of those four decimal places weren't both set to zero. See my attached 4.2 jpeg. Any chance we (by which I mean one of the sterling members of the gnucash development team) could display the exchange rates used to all 4 decimal places rather than effectively 2 as is now the case? For people who have to cope with exchange rate variations, this would be a much appreciated feature. Thanks again for your consideration and to the whole development team for this great product.
Yes, I was planning to reopen it anyway after re-reading your description on gnucash-user and realizing that the issue was really about the report going to two decimals when it shouldn't. This is partly a revisit to bug 797743 which complained of the opposite. Something has also broken the price editor so that it's ignoring force-prices-to-decimal being unset and always showing decimals. Prices in the register are displayed correctly
I've found and fixed the problem with the pricedb. Chris Lam has started https://github.com/Gnucash/gnucash/pull/802 to get the price/rate table in reports to also follow the force-decimal preference and to present all 4 digits when it's set.
Fixed exchange-rates table to show more precision, and also obey global pref 'force decimals'. Please test latest maint, or tomorrow's nightly flatpak on https://code.gnucash.org/builds/flatpak/maint/
Thanks for the quick fixes, guys. I've build gnucash from the maint branch $ gnucash --version GnuCash 4.2 development version Build ID: git 4.2-86-g946cbef95+(2020-10-26) and I can confirm the price database now retains the manually added exchange rates between sessions and the reports now display 4 decimal digits of the exchange rate used. However, slight problem: the reported exchange rate is a day out from the rate actually used in the report. My Edit -> Preferences -> Accounting Period -> End Date is set to Absolute: 30/09/20 I set my Balance Sheet report Options -> Commodities -> Price Source: nearest in time; My price database has exhange rates for GBP/AUD for 30/09/20 (1.80377) and 01/10/20 (1.794185). The report has a line: Barclays £1,531.75 $2,762.92 (which means it used the 30/09/20 exchange rate 1.80377) however the Exchange rates reported at the bottom of the report is £1.00 $1.7942 (i.e. the exchange rate from Price Database 01/10/20). Is this a separate problem?
May be a newly introduced bug. Try the following change to commodity-utilities.scm and let us know? @@ -767,6 +767,7 @@ (define (gnc:case-price-fn source target-curr date) (define pdb (gnc-pricedb-get-db (gnc-get-current-book))) + (define date (time64CanonicalDayTime date)) (case source ((pricedb-nearest) (cut gnc-pricedb-get-nearest-price pdb <> target-curr date)) ((pricedb-latest) (cut gnc-pricedb-get-latest-price pdb <> target-curr))
Also what's your timezone?
(In reply to Christopher Lam from comment #8) > May be a newly introduced bug. > Try the following change to commodity-utilities.scm and let us know? > > @@ -767,6 +767,7 @@ > > (define (gnc:case-price-fn source target-curr date) > (define pdb (gnc-pricedb-get-db (gnc-get-current-book))) Ok this was a bad patch. It makes the time64 into midday which may fix pricedb retrieval but will mess up the average-cost calculator. @jralls: Perhaps getting gnc_pricedb_get_nearest_price to do the time64CanonicalDayTime is the much better fix?
(In reply to John Ralls from comment #9) > Also what's your timezone? I also see this problem in GMT+8
Ok confirmed pricedb-nearest need to normalize date in guile code to mimic gnc:exchange-by-pricealist-nearest. Please try latest maint.
(In reply to Christopher Lam from comment #10) > (In reply to Christopher Lam from comment #8) > > May be a newly introduced bug. > > Try the following change to commodity-utilities.scm and let us know? > > > > @@ -767,6 +767,7 @@ > > > > (define (gnc:case-price-fn source target-curr date) > > (define pdb (gnc-pricedb-get-db (gnc-get-current-book))) > > Ok this was a bad patch. It makes the time64 into midday which may fix > pricedb retrieval but will mess up the average-cost calculator. > > @jralls: Perhaps getting gnc_pricedb_get_nearest_price to do the > time64CanonicalDayTime is the much better fix? Probably not. Prices have times, and the times that markets are open is determined by the local time zone for that market. You surely can ass a fixed UTC time to gnc_pricedb_get_nearest_price() but it may not produce the result you're looking for. Consider that the ASX opens at 23:30 UTC and closes at 05:30 UTC the next day; Tokyo opens at 21:30 and closes at 03:30 the next day; New York opens at 13:30 and closes at 21:00 the same day. Not one of them is open at the 10:59 we use for transactions to keep them in the same day in almost all TZs.
By gum, real-time bug fixing! It'll never through Management :-) Works a treat. Now displaying: Barclays £1,531.75 $2,762.92 £1.00 $1.8038 (both using 30/09/20 exchange rate 1.80377) Many thanks, once again, guys. What a team! $ gnucash --version GnuCash 4.2 development version Build ID: git 4.2-88-ga6c8a806f+(2020-10-27) I'm in UTC+11 (Sydney)
You're welcome! UTC+8 (WAust)
