GNOME Bugzilla – Bug 142424
QIF file parse failed: Data for number or date does not match a know format.
Last modified: 2018-06-29 20:43:30 UTC
Hello, I'm trying to import Bank account .QIF/.qk file and I get the above error window. I live in Italy and .QIF is generated from BancaIntesa internet home banking. The file has the followinf content: !Type:Bank D13/02/2004 T-8,99 N LPAGAMENTO POS PAGOBANCOMAT MCARTA 01234567 OPER. 12/02/04 18:36 C/O SUPERMERCATO IPERCOOP MILANO ^ If I change date line in D02/13/04 a dialog asks me for the date format, and choosing d-m-y it works. Is it possible for GnuCash to accept 4 digit year ? Also it should be nice to configure fields format once, maybe in configuration menus. Fabio
Hi, 13/02/2004 should be detected as 13 Feburary 2004 just fine by the parser. Yes, it accepts 4-digit years. However it may get confused if you have different dates in different formats throughout the file. For example, if you have: 13/02/2004 and 11/14/2003 This cannot be parsed properly because you have conflicting date formulas. Similarly for the number you could have conflicting formats... For the record, 1.8.9 can import the above transaction just fine without any problems. What version are you using? (reduced the severity because I cannot reproduce with data provided)
Hi, I was wrong thinking the problem was the 4 digit year number. I took a very long data file and i tried to select the guilty records. You can replicate the problem using the following lines. I'm using gnucash-1.8.9-1 on Fedora Core 2 Test 3 Fabio !Type:Bank D13/04/2004 T-17.500 N LRILASCIO ASSEGNI CIRCOLARI MEMISSIONE ASSEGNI CIRCOLARI ^ D13/04/2004 T-19,8 N LPAGAMENTO POS PAGOBANCOMAT MCARTA 01234567 OPER. 10/04/04 16:05 C/O FANTASIA MILANO (C.M.= 5641) ^
Thanks. Yes, I can reproduce with this data. It's quite clearly getting confused about the first number, 17.500, which can either mean 17 thousand 5 hundred or 17 and one-half (it's ambiguous). The second number is clearly 19 and 8/10 using a comma-as-decimal-separator. From a guess (without actually looking at the code) the parser is making a determination too early that it's a period-as-decimal-separator and then it finds the second number and blows out. This could be a regex issue or it could be something else, I don't know. One workaround: add ,0 to the end of the 17.500 so it looks like: 17.500,0 The importer will happily import it at this point (which unfortunately doesn't help in my diagnosis of whether it's a regex or an algorithm problem). At this point the existing QIF importer is EOLed and a new version is being written, so I'll keep this open to make sure this issue is handled. As for why there isn't a global option -- the reason is that different QIF sources could very easily use different formats! Thank you for your report. I'll take ownership.
Anything happend with this one?
nope, not yet. I'm starting to look at it right now. I figured out what's going on here, but there is still an ambiguity. Let's say I have these two numbers: 17.500 198 Is the first number seventeen and a half or seventeen thousand five hundred? I'll note that before AND after my patch it is assumed the former, not the latter. But I think I've solved this particular problem in trunk in r14523. Awaiting audit for backport.
Audited by jsled. Merged into 2.0 in r14561 for 2.0.1.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=142424. Please update any external references or bookmarks.