GNOME Bugzilla – Bug 786708
Currency decimals behave strangely when moving from XML-backend to sqlite-backend.
Last modified: 2018-06-29 23:58:42 UTC
This was tested on commit 29a92431cb85b6454c106d824ed5265bb1547525. When I add a currency with 8 decimals and recompile gnucash (for example, bitcoin), the following bug occurs. For brevity I will describe the steps to reproduce the bug as I describe the bug. Step #1: Add cryptocurrency to iso-4217-currencies.xml and rebuild. For example: <currency isocode="BTC" fullname="Bitcoin" unitname="bitcoin" partname="satoshi" namespace="ISO4217" exchange-code="2001" parts-per-unit="1" smallest-fraction="100000000" local-symbol="" /> Step #2: Create a brand new workbook, save it as XML. In the new workbook create an account using the BTC currency. In that account, add a transaction with 1/100000000 as the deposit. Notice how the transaction is shown as 0.00000001, which is correct. Step #3: Save the workbook, then reload. Notice that the transaction has now been truncated down to 0.00000000. Step #4: Save the workbook as a new file, now in sqlite3-format. Enter another transaction to account, 1/100000000, same as before. Notice how the transaction is now shown as 0.00000001, which is correct. Step #5: Save the workbook, then reload. Notice that the transaction has now been truncated down to 0.00. Note, not even the correct number of decimals anymore. Step #6: (Optional) Create a new workbook, save it as sqlite3. Create an account using the BTC currency, and add a transaction with 1/100000000 as the deposit. Save and reload the file. Notice how it is not truncated and still shown correctly, 0.00000001. This is the behavior I would expect in step #5 above.
In examining the workbooks from step #5 and step #6 in a sqlite browser, the primary difference I've found is that step #5 contains an entry for the bitcoin-currency in the 'commodities'-table, while the workbook from step #6 does not.
After investigating further it seems that when I create a brand new workbook using the sqlite3 backend from the beginning, create an account like above then create a 1/100000000 transaction, it still gets mangled when I save/load the workbook. Going from an existing XML workbook thus doesn't seem to be a big contributing factor. Perhaps this ticket should be closed, or taken as a bug report for the SQL backend.
GnuCash currently does not support currencies to more than 6 decimal places. The use of bitcoins has been discussed in the mailing list and there is an open bug for this; Bug 690479 The most common workround is to use milli-bitcoins which can be accommodated within the 6 DP limit.
Mike, This is a bug against master, which *is* supposed to support currencies of more that 6 digits. I asked the poster to file it after he described the problem on IRC.
Jonas, I've removed the forced-rounding to 6 digits from the code. Can you please re-test on 2.7.4 or later?
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=786708. Please continue processing the bug there and please update any external references or bookmarks.