GNOME Bugzilla – Bug 649362
Transfer Funds Window Exchange Rate and Decimal Points Rounding in Bill/Invoices
Last modified: 2018-06-29 22:57:41 UTC
Tested in MacOS 10.5.8, GnuCash 2.4.5, with Trading Accounting on (Even though this last information is not important) and EURO as main reporting currency When creating a bill of a vendor with currency payment information different than main reporting currency and expense account used in the bill is in the major currency, there is an issue with respect to the Transfer Funds window and Exchange Rate rounding. Example: Bill of vendor X paid in USD (payment information currency USD) Expense account of bill in EURO A/P in USD Quantity of Bill 1 Unit Price Amount 300 USD When posting the bill a warning message pops up saying that there is a transfer between different currencies and informs of request for exchange rate. Pressing ok, pops up the Transfer Funds window. Exchange Rate set to 1.3861 indicating 1 EUR = 1.3861 USD and 1 USD = 0.721449 EUR correctly. To Amount is automatically set incorrectly to 1.39 (equals exchange rate always rounded to second digit) instead of indicating amount (ie 216.4346). If changed to amount 238.07806 then exchange rate also changes to same amount rounded. If changed to 1.3861 and Exchange Rate is reselected both round to 1.39. No matter what I choose (ie Exchange Rate : 1.3861 or To Amount:1.39) and press ok, the final transaction is rounded based on the exchange rate of 1.39 instead of 1.3861. Final result Expense Account: 215.83 EUR instead of 216.4346 (or 216.43 rounded). Similarly the account Trading:CURRENCY:EUR is 215.83 EUR The result is the same whether Trading is on or off. On the other hand, if I do a transfer between accounts of different currencies the Exchange Rate is set correctly without any rounding and the To Amount is correctly indicated as 216.4346 in the Transfer Funds window, while the final Balance in the Expense Account is 216.43.
Just to add a bit on that: firstly when I said 238.07806 what I really meant was 216.4346. secondly, it seems like for invoices the accuracy of the exchange rates is enforced by the CURRENCY used (i.e. fraction of USD and/or EUR is set to 1/100 and cannot be changed by the securities editor). unlike the invoices, however, transferring between accounts with different currencies seems to allow accuracy of exchange rates different than the Security options of fraction traded (i.e. 1/100). not sure if that is the case, but seems as a probable cause. A similar bug was reported for currency exchange rates in Bug 641863. However, it is a slightly different issue there and does not involve bills/invoices and seems to be related to simple transfers between account of different currencies.
Thank you for your report. I can confirm this still happens in the latest stable (at present 2.4.7) and unstable (currently r21377) versions of GnuCash. Also the problem isn't OS X specific. I can reproduce it on linux as well.
*** Bug 631474 has been marked as a duplicate of this bug. ***
Created attachment 201785 [details] [review] Compute the exchange rate for amount=10000000 instead of amount=1 To the reporter and whoever else is bitten by this bug: I have also hit upon this problem. See this thread: http://lists.gnucash.org/pipermail/gnucash-user/2011-November/042020.html The cause of this bug is explained in that message. I am able to work around the bug by using this patch, which converts 10000000 into the target currency instead of just 1. The exchange rate is then computed more precisely. Note that the patch is not elegant and is a hack, but it makes the software work correctly instead of what happens with the current behavior. There is also a bug when you process payments. It auto-fills the amount in the customer's currency, instead of whatever payment that you received in your local currency (which you should actually fill in). That amount is assumed as the payment amount given in the local currency and converted back to the customer's currency using the transfer dialog which changes it to a radically different amount. This bug is also described in that thread. Anyway, this is just a UI quirk and can be worked around by filling in the correct amount in the local currency that was received.
Comment on attachment 201785 [details] [review] Compute the exchange rate for amount=10000000 instead of amount=1 I think it's a perfectly reasonable workaround to fix this particular rounding issue.
Comment on attachment 201785 [details] [review] Compute the exchange rate for amount=10000000 instead of amount=1 Thank you for your patch. I have chosen to fix the problem more profoundly though. I have been looking into this a bit deeper and found the exchange rate actions during posting very confusing. Take the original poster's example: The bill and post to account are in USD, which means all entries are entered in USD as well. The expense account is in EUR When posting, an exchange rate is asked from EUR to USD, which is technically backwards, and stores it internally like that. But it calculates from USD to EUR when actually posting. It does so by actually dividing by the exchange rate from EUR to USD instead of multiplying with an exchange rate from USD to EUR. This gives a very counter-intuitive experience. I have applied a patch in r21713 that fixes both the rounding issue and this confusing backward conversion question. While these are strictly speaking different issues, they were difficult to fix in independent patches.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=649362. Please update any external references or bookmarks.