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 779217 - Transactions rounded to 5 decimal places when opening file
Transactions rounded to 5 decimal places when opening file
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: General
2.6.15
Other Linux
: Normal normal
: ---
Assigned To: gnucash-general-maint
gnucash-general-maint
Depends on:
Blocks:
 
 
Reported: 2017-02-25 13:59 UTC by Anton Lindström
Modified: 2018-06-29 23:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Anton Lindström 2017-02-25 13:59:56 UTC 
I have an account in XAU. XAU has a fraction of 1 / 1000000. When working with it in Gnucash everything is as expected, but after saving and re-opening my file the least significant digit is lost by rounding.

Example:
If I create a transaction with 1.234567
After saving inside the xml file I correctly have:
<split:value>1234567/1000000</split:value>

But after closing gnucash and reopening the file I see:
1.234570
So 1.234567 has been rounded to 1.23457 and then the precision has be increased again to become 1.234570
After re-saving I have
<split:value>1234570/1000000</split:value>
in the file.

I'm using the XML backend.

Best regards,
Anton
Comment 1 Anton Lindström 2017-02-25 14:06:58 UTC 
Forgot to mention that this was reported long time ago in bug 150524 but that bug was closed as a duplicate of another bug, but the problem isn't fixed.
Comment 2 John Ralls 2017-02-25 15:27:08 UTC 
I can replicate this. Examining the file shows that the stored value is correct:
   <trn:split>
      <split:id type="guid">f0f7e5ea2c2877aa19eadb2e6b6a07f3</split:id>
      <split:reconciled-state>n</split:reconciled-state>
      <split:value>1234567/1000000</split:value>
      <split:quantity>1234567/1000000</split:quantity>
      <split:account type="guid">425bb0a9897c09b1ec508dc18f6d2f87</split:account

I expect that there's a SIGFIG 6 rounding in the loading code: Creating another transaction for 1.000005 oz gets rounded up to 1.000010 and the balance becomes 2.234580.
Comment 3 John Ralls 2017-03-10 21:22:12 UTC 
Not quite: It turned out to be the default denom in gt_currency_denom was 100000 instead of 1000000.

This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
Comment 4 John Ralls 2018-06-29 23:54:51 UTC 
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=779217. Please update any external references or bookmarks.