Created attachment 372929 [details] Offending OFX file I cannot import the attached ofx file using a recent install of GnuCash 3.2. I am pretty sure it is not a FITID issue. Can anyone confirm?
OFX import works fine on Linux Mint 19 with v 3.2
(In reply to David Cousens DaveC49 from comment #1) > OFX import works fine on Linux Mint 19 with v 3.2 I am sorry but I use Windows. In my Windows 10 machine it does not work at all.
Are there any libofx errors in the tracefile? (https://wiki.gnucash.org/wiki/Trace_File). If not, try opening a shell (powershell or cmd.exe) and run "c:\Program Files (x86)\gnucash\bin\gnucash.exe" then try your import. Is there any output to the console?
John, Gilberto I am importing an OFX file I had previously imported in GnuCash v3.2 on Linux Mint 19 into GnuCash 3.2 running under Windows 10 on a Samsung TabProS without any problems. David
Johm, Gilberto, Also imported Gilberto's attached OFX file into GnuCash 3.2 , Windows 10 on the TabPro S without any problem. David
Hi Gilberto, My main reason for commenting was to let the developers know that OFX importing was working OK on Linux systems, so the problem is confined to Windows versions. Just saves them trying to chase it as a general problem and narrows the areas they have to look at. David
(In reply to David Cousens DaveC49 from comment #5) > Johm, Gilberto, > > Also imported Gilberto's attached OFX file into GnuCash 3.2 , Windows 10 on > the TabPro S without any problem. > > David Apologies, there is a problem with the import of Gilbertos file under both Windows 10 and Linux. The split into the transfer account is created but the split into the account it is being imported into is not being created in both cases. In th eimport matching window the transaction amounts are all showing as 0.00 whereas in an import of an OFX file from my own bank, the amount column has values and the split into the account being imported to has a non-zero value. There is a difference in the format of a transaction in Gilberto's file: <STMTTRN> <TRNTYPE>DEBIT</TRNTYPE> <DTPOSTED>20180201</DTPOSTED> <DTAVAIL>20180201</DTAVAIL> <TRNAMT>-250</TRNAMT> <FITID>2018.02.01.001</FITID> <CHECKNUM>00000000</CHECKNUM> <NAME>DEBITO AUT. ESTACIONAMENTO SAN EST PRED</NAME> <MEMO>GRUPO SANTANDER BRASIL</MEMO> </STMTTRN> and in my file which does load successfully: <STMTTRN> <TRNTYPE>DEBIT <DTPOSTED>20180730 <DTUSER>20180730 <TRNAMT>-35.00 <FITID> <MEMO>Direct Debit 085236 MISSION AU MISAUS2226331288 </STMTTRN> One obvious difference is the lack of closing tags within the <STMTTRN></STMTTRN> tags and some other aggregate blocks in Gilberto's file. I'm no expert but a very quick look through the OFX2.2 standard suggest that within the <STMTTRN></STMTTRN> aggregate block there should be no closing tags on the data elements. (e.g. see p215 http://www.ofx.net/downloads/OFX%202.2.pdf). If libofx is not setup to ignore unnecessary tags it may be bombing out on those redundant closing tags. David
David, thanks for diving into the issue. The closing tags in the file I tried to import is related to the OFX standard version I believe. I do not quite recall which OFX version to be honest and I cannot comment in detail on the standard per se because I do not know it. What I think is strange is that this file I uploaded (with closing tags) is imported successfully by the 2.4.X versions of Gnucash in my Win10 machine. That may narrow down the issue for the developers. Regarding John's suggestions I will try to obtain the information. Thank you all for the help.
(In reply to gilberto.reis.filho from comment #8) > David, thanks for diving into the issue. > > The closing tags in the file I tried to import is related to the OFX > standard version I believe. > > I do not quite recall which OFX version to be honest and I cannot comment in > detail on the standard per se because I do not know it. > > What I think is strange is that this file I uploaded (with closing tags) is > imported successfully by the 2.4.X versions of Gnucash in my Win10 machine. > That may narrow down the issue for the developers. > > Regarding John's suggestions I will try to obtain the information. > > Thank you all for the help. Correcting: 2.6.X Gnucash versions import this file without a problem.
