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 657402 - Max fraction is too low e.g. for Bitcoin
Max fraction is too low e.g. for Bitcoin
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Engine
git-master
Other All
: Normal normal
: ---
Assigned To: John Ralls
Christian Stimming
: 720561 (view as bug list)
Depends on: 648829
Blocks: 690479
 
 
Reported: 2011-08-26 06:28 UTC by matthias
Modified: 2018-06-29 23:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
demonstrating both problems (2.01 KB, application/x-gnucash)
2011-08-26 06:28 UTC, matthias
Details
Test_1.gnucash (2.30 KB, application/x-gzip)
2011-09-30 02:55 UTC, Frank H. Ellenberger
Details

Description matthias 2011-08-26 06:28:24 UTC
Created attachment 194786 [details]
demonstrating both problems

Currently, there is no way to track Bitcoins accurately because the maximum number of digits which Gnucash appears to be six.

Bitcoins are spec'd to have eight digits to the right of the decimal point.

This applies both to new commodities and the test currencies.
Comment 1 Frank H. Ellenberger 2011-09-30 02:55:38 UTC
Created attachment 197837 [details]
Test_1.gnucash

Hello, 

for misusing XXX/XTS you are right, they are hardcoded in src/engine/iso-4217-currencies.scm. Should I fix.

But I have no problem to enter amounts with 8 decimals in an account of type funds with your BTC commodity as you can see in my updated file.
Comment 2 matthias 2011-12-13 17:44:47 UTC
Looking at the numbers in your test file's Assets:Coins account:

* the number of shares is rounded to 6 decimals even though the asset in question has 8.

* 100.123460 != 100.123457. Where does the first number come from? Nobody told gnucash to round off at five digits AFAICT.
Comment 3 Frank H. Ellenberger 2012-12-19 15:00:03 UTC
Indeed, the opening transaction contains:

      <split:value>1234568/1000000</split:value>
      <split:quantity>12345678/100000000</split:quantity>

So the value is always rounded despite the commodity is declared with 8 decimals - while the quantity is accepted;
and as follow up on the other side:

      <split:value>-1234568/1000000</split:value>
      <split:quantity>-1234568/1000000</split:quantity>

Hm, we should ask the engine devs.

FYI: 
There is already a separate bug 648829 against the SQL backend.
Bug 690479 has a precise descripion and possible workarounds of the by bitcoin required precision.

Links from the following duplicate:
http://gnucash.uservoice.com/forums/101223-feature-request/suggestions/2277730-bitcoin and
http://www.reddit.com/r/Bitcoin/comments/152r33/gnucash_should_support_bitcoin/
Comment 4 Frank H. Ellenberger 2013-02-26 18:03:51 UTC
As workaround Warlord suggested on IRC [http://lists.gnucash.org/logs/2013/02/2013-02-26.html#T12:56:20] to track in milli-Bitcoins: 
So you record 1.23456789BTC as 1234.56789 mBTC
Comment 5 John Ralls 2013-12-16 21:40:18 UTC
*** Bug 720561 has been marked as a duplicate of this bug. ***
Comment 6 John Ralls 2018-06-29 23:00:31 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=657402. Please continue processing the bug there and please update any external references or bookmarks.