This appears to be something specific to Chase (or QFX files?).  I just successfully imported OFX files from a financial institution without problem.

However, note that the date format is different on this transaction.

Here is a successful OFX transaction

<STMTTRN>
<TRNTYPE>CHECK
<DTPOSTED>20190116000000[-8:PST]
<TRNAMT>-13.68
<FITID>99999999
<CHECKNUM>160
<NAME>CHECK # 160
</STMTTRN>

That's just not a date format that is valid in the OFX specification.

It is a QFX file, so if I understand correctly the specification is not published and it can be whatever Intuit decides :-(

The bottom line is that Chase used to work (at least as late as January 15, 2019) and now it doesn't.

Past experience says that Chase will not change anything and it will be up to Gnucash to change things or develop a conversion script for the .qfx file.

FWIW - in case anyone is interested in the datetime format, here is an excerpt from the OFX version 2.2 specification:

3.2.8.1 Dates, Times, and Time Zones
There is one format for representing dates, times, and time zones. The complete form is:
YYYYMMDDHHMMSS.XXX [gmt offset[:tz name]]

One more comment.  25+ years ago I would have whipped out an awk or sed script to fix things in a few minutes.  Though right now I'd spend half a day trying to remember which one to use and then relearning the commands :-)

My hope is that someone still current in awk/sed will come up with a work around (and one that would be better than my clumsy attempt) and then a permanent change to GnuCash will occur.

I don't suppose you have any Chase downloads from before the 15th lying around so you could check if Chase changed the date format.

Yes, thanks! I happened to find one in my recycle bin, dated Jan 18, 2019

Here is a transaction from the file.  It has a different date format

<STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20181217120000[0:GMT]
<TRNAMT>20.38
<FITID>2018121774164078350091012308241
<NAME>TARGET        00002675
</STMTTRN>

I'll ask Chase what happened, but I'd be willing to bet virtually all I own that I'll never get a meaningful answer.

I wouldn't take that bet.

Note that the FITID of "NONE" implies that all transactions have the same value. That's also non-compliant and GnuCash will think that all transactions are duplicates of the first one it sees like that.

I did document the problem to Chase.  Will let you know what happens.

In the meantime I kludged together a DOS script and an awk script to put things into the proper format (you'll need to change the time offset for your locale)



----------------DOS Script to invoke the awk script
@echo off
REM Stdin  = Bad QFX file
REM Stdout = Corrected QFX file
awk -f .\FixChaseQFX.awk


----------------FixChaseQFX.awk script
# Fix Chase's incorrect DTPOSTED format
# GOOD Chase Format: <DTPOSTED>20190116000000[-8:PST]
# BAD  Chase Format: <DTPOSTED>01/13/2019
# OFX Specification YYYYMMDDHHMMSS.XXX [gmt offset[:tz name]]

{
	if (substr($0,1,10) == "<DTPOSTED>") {
		print "<DTPOSTED>" substr($0, 17, 4) substr($0, 11, 2) substr($0, 14, 2) "000000[-8:PST]"
	} else {
		print $0;
	}
}

My bad!  Idiot here.  Haste makes waste!

I just looked at the DTPOSTED change, which worked perfectly, and thought I was golden.

The transaction dates still remained the same when I ran it against GC.

Every FITID in the file was "NONE"

I don't know the particulars of how the OFX/QFX transaction matching works.  Would there be any problems if I started FITID with 0001 and incremented with each new transaction, especially if I subsequently downloaded the same transaction in another download?

Alternatively, Chase has a CSV, QIF, IIF, and QBO download options.  Would any of these be good alternative, assuming they works as advertised?  I have the no idea the pros and cons of each one.

Thanks!

The only requirement for FITID is that it must be unique. Well, there's probably also a length requirement. I'd think that the safest solution would be something like a date string (e.g. 20190122) + a serial number. A plain serial number would work too but a four-digit one as you propose would cause some sort of trouble (what sort depends on implementation) at the 10-thousandth transaction.

GnuCash can also import QIF, so if that works for you it would be less work than fixing the OFX imports every time.

(In reply to Ed from comment #10)
> I don't know the particulars of how the OFX/QFX transaction matching works. 
> Would there be any problems if I started FITID with 0001 and incremented
> with each new transaction, especially if I subsequently downloaded the same
> transaction in another download?

If you give a different FITID to the same transaction on subsequent download, the transaction will be imported twice in gnucash, since the very purpose of FITID is to make it unambiguous if two transactions are or aren't the same.

I tried QIF but I couldn't get it to work for me.  The import didn't have any errors but I had no transactions displayed.

I then modified the awk script (now gawk) to change the FITID as you suggested.  The transactions still have the current date.

Here is the start of the modified QFX file with the first three transactions and the last transaction.  Any ideas on what the problem could be?

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE
<OFX>
<SIGNONMSGSRSV1>
<SONRS>
<STATUS>
<CODE>0
<SEVERITY>INFO
</STATUS>
<DTSERVER>20190121120000[0:GMT]
<LANGUAGE>ENG
<FI>
<ORG>B1
<FID>10898
</FI>
<INTU.BID>10898
</SONRS>
</SIGNONMSGSRSV1>
<CREDITCARDMSGSRSV1>
<CCSTMTTRNRS>
<TRNUID>1
<STATUS>
<CODE>0
<SEVERITY>INFO
<MESSAGE>Success
</STATUS>
<CCSTMTRS>
<CURDEF>USD
<CCACCTFROM>
<ACCTID>[my account number]
</CCACCTFROM>
<BANKTRANLIST>
<DTSTART>20190121120000[0:GMT]
<DTEND>20190121120000[0:GMT]
<STMTTRN>
<DTPOSTED>20002090000000[-8:PST]
<TRNTYPE>CREDIT
<TRNAMT>13.93
<FITID>2019012400000
<NAME>TARGET        00002675
</STMTTRN>
<STMTTRN>
<DTPOSTED>20002090000000[-8:PST]
<TRNTYPE>DEBIT
<TRNAMT>-106.96
<FITID>2019012400001
<NAME>TARGET        00002675
</STMTTRN>
<STMTTRN>
<DTPOSTED>20002090000000[-8:PST]
<TRNTYPE>DEBIT
<TRNAMT>-215.82
<FITID>2019012400002
<NAME>TARGET        00002675
</STMTTRN>

... 

<STMTTRN>
<DTPOSTED>27002081000000[-8:PST]
<TRNTYPE>DEBIT
<TRNAMT>-36.44
<FITID>20190124000077
<NAME>PAYPAL *MACY S
</STMTTRN>
</BANKTRANLIST>
<LEDGERBAL>
<BALAMT>-[my balance]
<DTASOF>20190121120000[0:GMT]
</LEDGERBAL>
<AVAILBAL>
<BALAMT>[my balance]
<DTASOF>20190121120000[0:GMT]
</AVAILBAL>
</CCSTMTRS>
</CCSTMTTRNRS>
</CREDITCARDMSGSRSV1>
</OFX>

(In reply to Benoit Grégoire from comment #13)
> (In reply to Ed from comment #10)
> > I don't know the particulars of how the OFX/QFX transaction matching works. 
> > Would there be any problems if I started FITID with 0001 and incremented
> > with each new transaction, especially if I subsequently downloaded the same
> > transaction in another download?
> 
> If you give a different FITID to the same transaction on subsequent
> download, the transaction will be imported twice in gnucash, since the very
> purpose of FITID is to make it unambiguous if two transactions are or aren't
> the same.

Thanks.  This makes sense.  It is looking more and more like I need to figure out how to do a QIF import.

Here is an example bank account (not credit card - sorry I don't have a credit card account at a bank that provides OFX) ofx file that imports correctly into GnuCash.

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE
<OFX>
<SIGNONMSGSRSV1>
<SONRS>
<STATUS>
<CODE>0
<SEVERITY>INFO
</STATUS>
<DTSERVER>20190119102110
<LANGUAGE>ENG
</SONRS>
</SIGNONMSGSRSV1>
<BANKMSGSRSV1>
<STMTTRNRS>
<TRNUID>1
<STATUS>
<CODE>0
<SEVERITY>INFO
</STATUS>
<STMTRS>
<CURDEF>AUD
<BANKACCTFROM>
<BANKID>4321
<ACCTID>12345678
<ACCTTYPE>SAVINGS
</BANKACCTFROM>
<BANKTRANLIST>
<STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20181231000000
<TRNAMT>45.95
<FITID>941495.20181231.45.95
<MEMO>Bonus Interest Credit - Receipt 941495
</STMTTRN>
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20181228000000
<TRNAMT>-3007.71
<FITID>835909.20181228.-3007.71
<MEMO>Tfr Receipt 835909 - To xxxxx
</STMTTRN>

... other transactions

</BANKTRANLIST>
</STMTRS>
</STMTTRNRS>
</BANKMSGSRSV1>
</OFX>

Note that there is no [offset:Timezone] on the end of my dates and the order of the fields within each transaction is different.
Maybe this will help...

The strange FITID is generated by a java program I use to massage the file before import.
See https://github.com/goodvibes2/IngAusOfxFixWin

Chris,
Thanks!  It made me look further into the differences between my old, working Chase download and the new, broken one.

After correcting the DTPOSTED and FITID problems I noticed a difference in the order of the elements within a STMTTRN.

Old and working element order:
<TRNTYPE>
<DTPOSTED>

New and failing element order:
<DTPOSTED>
<TRNTYPE>

I edited my download to a single transaction, ordered the two elements in the "old" manner and the transaction date was correct when importing.

I restored the order of the two elements to the current Chase download and the transaction date was incorrect.

Should the order of these elements make a difference to GnuCash?

Humm, I don't know why my previous message didn't make it.

Yes, the order of elements DO indeed make a difference.  OFX is a SGML standard, the elements have to follow the order in the OFX dtd file.

I don't know where or if there is a dtd file but if you want to tell Chase where the order is specified:
Go to http://www.ofx.net/downloads.html
Download the Version 1.0.2 zip file
and see section 11.4.2.3.1 Statement Transaction <STMTTRN>
in Ofexfin4.doc :

<STMTTRN>	Statement-transaction aggregate
 <TRNTYPE>	Transaction type, see section 11.4.2.3.1.1 for possible values
 <DTPOSTED>	Date transaction was posted to account, datetime
 <DTUSER>	Date user initiated transaction, if known, datetime
 <DTAVAIL>	Date funds are available, datetime
 <TRNAMT>	Amount of transaction, amount
 <FITID>	Transaction ID issued by financial institution.
                Used to detect duplicate downloads, FITID 
etc

I spoke with Chase support and was told that Quicken-provided software formats the QFX downloads.  Chase programmers have no part in the process, other than to provide the raw transaction data to Quicken code.  (Makes me worry about other financial institutions that provide QFX downloads).

They are reporting the problem to Quicken but I will have no feedback on what happens.

I wrote a qawk script that fixes the Chase problems.  The FITID is a bit of a kludge but the GnuCash importer (at least in my case) identified previously entered transactions as matches and were not duplicately posted.

----------------DOS Script to invoke the gawk script
@echo off
REM Stdin  = Bad QFX file
REM Stdout = Corrected QFX file
gawk -f .\FixChaseQFX.gwk


----------------FixChaseQFX.gwk script
# Fix Chase's incorrect DTPOSTED and FITID, and reorder
#OFX DTPOSTED Specification YYYYMMDDHHMMSS.XXX [gmt offset[:tz name]]
#GOOD Chase Format: <DTPOSTED>20190116000000[-8:PST]
#BAD Chase Format: <DTPOSTED>01/13/2019

#Legal FITID <FITID>yyyymmddTransactionID
#BAD Chase Format: <FITID>NONE
# Note that this provides a very simplistic transaction id, so be specific as
# to the transactions you download and check to make sure you don't post
# a transaction multiple times.

# TRNTYPE should appear before DTPOSTED


BEGIN{
	date=strftime("%Y%m%d"); #default date (Should never be used)
	tid=0;
	old_date="";
}
{
	# Capture, reformat and reorder STMTTRN data
	# Assumes that only TRNTYPE, DTPOSTED, TRNAMT, FITID, and NAME exist
	# and that DTPOSTED appears before FITID
	if (substr($0,1,9) == "<STMTTRN>") {
		print $0;
		getline;
		while (substr ($0, 1, 10) != "</STMTTRN>") {
			if (substr($0,1,9) == "<TRNTYPE>") {;
				TRNTYPE = $0;
				getline;
			} else if (substr($0,1,10) == "<DTPOSTED>") {
				date = substr($0, 17, 4) substr($0, 11, 2) substr($0, 14, 2)
				DTPOSTED = "<DTPOSTED>" date "000000[-8:PST]";
				# Reset the transaction id when the date changes
				# hopefully will reduce duplicates
				if (date != old_date) {
					tid = 0;
					old_date = date;
				}
				getline;
			} else if (substr($0,1,8) == "<TRNAMT>") {;
				TRNAMT = $0;
				getline;
			} else if (substr($0,1,7) == "<FITID>") {;
				FITID =  "<FITID>" date tid++; # date from transaction's DTPOSTED
				getline;
			} else if (substr($0,1,6) == "<NAME>") {;
				NAME = $0;
				getline;
			} 
		}
		print TRNTYPE;
		print DTPOSTED;
		print TRNAMT;
		print FITID;
		print NAME
		print $0
	} else {
		# Not part of a STMTRN, simply pass through
		print $0;
	}
}

NOTE: Quicken appears to have corrected their DTPOSTED format, but FITID and the order of the STMTTRN elements are still incorrect.

Be sure and check the downloaded file contents and adjust the gawk script as needed.

Quicken has now also corrected the order of the STMTTRN elements.  FITID is still "NONE" but GnuCash is importing the QFX file without issue and correctly matches previously posted transactions (fingers crossed that no other issues come up).

Thanks to everyone for your assistance.

(In reply to Ed from comment #22)
> Quicken has now also corrected the order of the STMTTRN elements.  FITID is
> still "NONE" but GnuCash is importing the QFX file without issue and
> correctly matches previously posted transactions (fingers crossed that no
> other issues come up).
> 
> Thanks to everyone for your assistance.

I still don't seem to be able to import from Chase!

jb have you examined your download file following Ed's example to ascertain whether you're getting incorrectly-formatted OFX?

jb,
As you have not replied to the question asked over a year ago, I'm closing this bug. If you wish to continue, and can you please reopen this bug and answer the question.