After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 427948 - Precision cut off at 2 digits for USD transfer between two 6-digit accounts
Precision cut off at 2 digits for USD transfer between two 6-digit accounts
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
2.2.x
Other All
: Normal normal
: ---
Assigned To: David Hampton
Chris Shoemaker
Depends on:
Blocks:
 
 
Reported: 2007-04-09 18:00 UTC by Jason W
Modified: 2018-06-29 21:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jason W 2007-04-09 18:00:53 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?
Comment 1 Derek Atkins 2007-04-09 18:11:38 UTC
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".
Comment 2 Greg Brown 2008-09-19 19:12:55 UTC
Still seems to be happening in version 2.2.6 on Linux (Ubuntu 8.04).
Comment 3 Frank H. Ellenberger 2011-04-10 05:01:38 UTC
FYI: Bug 408444 - "Smallest fraction" disregarded is related, but use also conversion between 2 currencies. Probably a dupe.
Comment 4 ben@benkraus.com 2011-04-10 05:49:27 UTC
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).
Comment 5 Jason W 2011-04-10 14:48:33 UTC
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.
Comment 6 Jean-Christian Imbeault 2012-04-02 12:46:24 UTC
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?
Comment 7 Manuel Amador (Rudd-O) 2012-06-14 03:19:21 UTC
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.
Comment 8 John Ralls 2018-06-29 21:31:11 UTC
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.