GNOME Bugzilla – Bug 598228
transactions should be handled/stored in the currency with the lowest value to avoid rounding errors
Last modified: 2018-06-29 22:29:44 UTC
Created attachment 145322 [details] really_different_currencies Attached is an example for transactions between really different valued currencies. This example uses an exchange rate of 1,00 EUR = 10 000,00 IDR for simpler reading/calculation. You can see the different results in Assets:Current Assets:Cash in Wallet:IDR, depending of the starting account of your TXN. If you start the txn in EUR all IDR are rounded upto 50 IDR up and down, which makes it difficult to enter invoices. So I think, if an transaction got the FX rate of a new affected currency, it should determinate the smallest used currency with the lowest value and use that for all further calculations instead of the currency of the first used account. In my eyes a simple mathematical thought: reduce rounding errors. The book shows also some other bug, but that can we discuss later...
Hm, the new bugzilla interface ... I forgot to annotate the file was made with svn r18377. And I am not shure, if the component should be engine or register.
The correct solution to this problem is to use a multi-precision library like gmp or Boost::Multiprecision instead of gint64 inside of gnc_numeric.
(In reply to comment #2) > The correct solution to this problem is to use a multi-precision library like > gmp or Boost::Multiprecision instead of gint64 inside of gnc_numeric. Why is that? Isn't this a SCU problem instead (six significant digits)? The described rounding error isn't caused by the gint64 quantization, is it?
Not 6 digits of SCU, the Euro has 2 digits (smallest fraction is 100, as is the case with most currencies). Since €.01 = 100 IDR, I guess that's what Frank means by "rounded up to 50IDR": 150 IDR would be rounded up 50 IDR to make €.02. So you're right, not a numerical overflow in this case. I think this requires a rethink on SCU: It would have to be used only for display, not for the currency's calculation denominator. That would be a significant design change, I think. Frank's idea of selecting the "smallest" currency for a forex transaction would be a little easier, but not quite right: It needs to be the currency with the smallest useful fractional value. For example, a Bitcoin is currently trading at around $1000, but its smallest unit is 10E-9 Bitcoin which is still a millionth of a US Dollar, a much smaller value than can be represented in dollars. The change to the transaction currency could be called from gnc_split_register_handle_exchange(), though the function itself should be in Transaction.
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=598228. Please continue processing the bug there and please update any external references or bookmarks.