-
Notifications
You must be signed in to change notification settings - Fork 540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Precision may be lost when saving the exchange rate in the database #479
Comments
I'm working on a fix. By the way, should we be storing the exchange rate calculated from the user entered converted amount? Given the precision problems, I'd rather store exchange rate only when the user enters it explicitly. |
Thanks for catching this @rivaldi8 And yes, we should still save the rate when the user only entered the converted amount. This is used for convenience the next time the user creates another transaction with the same currencies. |
We were storing the rate as originAmount/convertedAmount, which was limited to the precision of the currencies. Now we store directly the entered rate. Fixes codinguser#479
@rivaldi8 The (you can checkout the current develop and test this) |
The call to If you are ok with it, I can fix the unit test. |
oh sure, please go ahead and fix the test. Thanks 👍 |
@rivaldi8 never mind. I'll fix it. I'm in the midst of some changes already anyway :) |
Ok, as you will :) |
…nator. Fixes a regression introduced in 66cc533 (bugfix codinguser#479) in which the numerator/denominator division fails with an ArithmeticException if no MathContext is provided. BigDecimal tries to return an exact result, which is not possible when rounding and precision aren't specified. See BigDecimal javadoc: http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html Fixes Crashlitics issue codinguser#196 https://fabric.io/gnucash/android/apps/org.gnucash.android/issues/571b4a95ffcdc04250f98ba0
When the user enters an exchange rate, it's not saved directly. Instead, the
relation between the original amount and the converted amount is stored. As a
consequence, the exchange rate precision will depend on the precision of the
two currencies.
In addition, the converted amount is (wrongly) stored with the currency of the
original amount and rounded to its decimal places. If the original amount has
no decimal places, even more precision is lost.
For example, if the user transfers from a Yens account (no decimal places) to an
Euros account (2 decimal places) and enters:
GnuCash calculates:
GnuCash should store directly the exchange rate instead of calculating it.
The text was updated successfully, but these errors were encountered: