GNOME Bugzilla – Bug 721447
Entries with values of ,50 are imported as ,51
Last modified: 2018-06-29 23:23:32 UTC
Created attachment 265301 [details] Sample QIF file that is imported incorrectly On my box (Windows 8.1 x64, english, format - in Clock, Language and Region control panel - as Portuguese, LANG/LANGUAGE env vars set to en_US) importing entries with a decimal value of ,50 (for instance 2,50)creates an entry with a decimal value of ,51 (for instance, importing 2,50 ends up as 2,51). On version 2.4.13 this works as expected.
This is probably due to the change in rounding that was backported to 2.4.14. I bet it fails in 2.6, too, right?
*** Bug 721593 has been marked as a duplicate of this bug. ***
I tested only with 2.6 (in which it fails) and 2.4.13 (works).
Can you verify 2.4.14?
sure, I'll and post the results here later
Created attachment 265470 [details] Correctly import in 2.4.14
Created attachment 265471 [details] Failed import on 2.6
Hi, I could not reproduce the issue with 2.4.14 on a VM. What I did: 1. Installed 2.4.14 2. Created an new GNU Cash file. 3. Imported the sample file attached in this issue (worked) 4. Installed 2.6 and repeated steps 2 & 3. The issue happend.
FWIW, I am also seeing this in 2.6 on two different Windows 7 x86 machines. I have seen the following errors on split transaction imports: QIF --> Gnucash .83 .85 .78 .79 .73 .72 .65 .66 .64 .65 .63 .64 .50 .51 .42 .41 .41 .40 .40 .39 .34 .33 .03 .04
Comment on attachment 265301 [details] Sample QIF file that is imported incorrectly Please mark text files as text/plain instead of octet/stream
Importing the file under Linux I get the right values. So it seems to be a Windows issue. Probably related is Bug 721825 - Online prices displayed as unreadable fractions in 2.6.0
(In reply to comment #8) > Hi, I could not reproduce the issue with 2.4.14 on a VM. Was that a Windows VM or a Linux VM? As Frank notes, this problem appears to be Windows only.
Windows 8, 32bits (as I said, I can reproduce the issue in that VM but only on GnuCash 2.6)
*** Bug 721825 has been marked as a duplicate of this bug. ***
r23721. (int)pow(10, 2) was returning 99 instead of 100, which created a result that was both correct and impossible to convert back to an exact decimal, at least using our extremely lame gnc_numeric_to_decimal function. In this case, that resulted in inappropriate rounding.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=721447. Please update any external references or bookmarks.