GNOME Bugzilla – Bug 427948
Precision cut off at 2 digits for USD transfer between two 6-digit accounts
Last modified: 2018-06-29 21:31:11 UTC
Taken from a post to gnucash-users: I'm using GNUcash 1.8.11 on Mac OS X 10.4.9 (PPC) as compiled from fink. I have several loans at Prosper ( http://www.prosper.com ), a microcredit company that sells small shares of loans. Prosper reports on my loans to six decimal places: e.g. one of my loans is presently valued at $47.845890. I created two accounts to set up my loans. Equity:Prosper Opening Balances is an Equity account where the commodity is USD and the smallest fraction is 1/1000000. Assets:Microcredit:Prosper:2741 is an Asset account. When I try to record the opening balance, the dollar amount is truncated at two decimal places but still displays with the extra decimal places: $47.840000. Is there any way to mix USD-2 accounts with USD-6 accounts? I'd really rather keep my regular bank accounts with their normal two post-decimal digits of precision. And from a reply by Derek Atkins: Strangely this is still an issue in 2.0. File a bug report?
For the record, I see it in the current 2.0 branch on Linux (FC5) I've updating the "Version" to 2.0.x so this bug doesn't get closed. I've also updated the OS to "All".
Still seems to be happening in version 2.2.6 on Linux (Ubuntu 8.04).
FYI: Bug 408444 - "Smallest fraction" disregarded is related, but use also conversion between 2 currencies. Probably a dupe.
According to the Wikipedia page on USD (and personal experience), the smallest unit for US Dollars is $0.001, not $0.01, so the smallest currency unit for USD should be changed, but it appears hard-coded. $0.001 is regularly used, for example gas prices are almost universally listed with that precision (for example, $3.019/gallon). http://en.wikipedia.org/wiki/United_States_dollar I encountered this issue when I tried to create an account with USD as the commodity and the smallest fraction set to 1/1000. However, the smallest fraction setting is being ignored in favor of the smallest commodity unit for the USD (which is set to 1/100). If I change the smallest fraction to 1/1000, the account tab lists each value with three decimal places, but the last decimal place is always 0. When I click on a value to edit, the third digit disappears, but I'll type it anyway. When I click "tab" or move to another field, the value is rounded to the nearest 1/100 and the third digit remains 0. I originally tested in 2.2.9, then again in 2.4.4. The only difference between the two was in 2.2.9 the value was rounded down from $17.665 to $17.660, while in 2.4.4 the value was rounded up to $17.670. I filed an enhancement bug (bug 647340) requesting a mechanism to allow users to change this value on their own, which would help resolve the original bug posters problem. Finally, bug 408444 is related to this issue (a currency with an incorrect smallest fraction).
The smallest unit for U.S. dollars is not 1/1000 regardless of what Wikipedia says. Prosper tracks accounts down to six post-decimal digits because it deals with loans that have been parted out in very small measures. GNUCash should support any precision the user wants for any currency.
I've just hit this bug. I have accounts in JPY and am unable to create transactions with any decimals. Just curious but this bug report has been here for *5* years and is still in the unconfirmed state?
Happens in latest stable version, compiled fromm downloaded sources. I try to enter a transaction in a currency that has six decimal places and BOOM, precision cut to 2 decimals, regardless of what the options say.
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=427948. Please continue processing the bug there and please update any external references or bookmarks.