OL-221-A QFX import error for pre-existing transactions after FID (routing # change)
This is a strange Quicken bug related to accounts that have migrated to a new FID (Bank Routing #) when one bank has merged with another. When trying to import a QFX file, if the file contains already-imported transactions (when the former FID was in use), Quicken throws an OL-221-A error, when trying to import the QFX file (immediately, before any dialogs, e.g. to associate with a new or existing account). If you edit the QFX file and remove any prior transactions (STMTTRN records with a FITID that pre-existed, i.e. prior to the takeover by the new bank), the QFX file can be imported and associated etc.
The straightforward solution to this problem (avoiding the need to edit the QFX files) seems to be to select only new transactions when downloading, by date range. However that could be a real pain as you might need to do that forever for some banks, as they may by default include all prior transactions….
Overall I consider this a Quicken error as it should ignore any pre-existing STMTTRN (FITID matching) records, regardless of the FID for the QFX file overall. I also consider it a high-priority bug as it may block any users of Quicken when banks merge, and the FID changes.
Comments
-
As far as I know that isn't how it works. The FIT and the FITID might look similar, but there really isn't any connection between them. The FIT is the Inuit assigned number for the financial institution. The FITID is the transaction Id assigned by the financial institution. This string could be any string, it has nothing to do with the FIT. In fact, when people want to reimport a transaction one method is to change the FITID by adding a character to it either at the beginning or the end or basically changing it any way.
Why Quicken would now consider an old working FITID invalid is hard to say. The Connection log might have more details in it. Help → Contact Support → Log Files → Connection Log
Note this the first time I have ever heard of a problem like this and the OFX standard that Quicken uses hasn't changed in decades, and certainly many people including myself have had financial merge, so I don't know what is going on.
Also, I of course can't be 100% sure since I don't have the code, but there isn't any reason for storing the FITIDs by FIT. The FIT is an account level parameter, that would change when the financial institution merged.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
The FID (not FIT) is what I was referring to. It is the Bank Routing #. The FITID is an identifier generated by the bank for a specific transaction (STMTTRN element in the file). The issue here is (or seems to be) simply related to a prior FITID being associated with a prior FID, and then associated with a new FID used by the new bank. The FID is a sub-element of the FI (Financial Institution) node in the QFX file.
0 -
Yes, I goofed and typed FIT when I meant FID. I see no reason why there would be any "association" between the prior FID and the the FITID, in fact I would think the the FID would be removed when you deactivate so that you can associate it with the the new FID.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
NP, and yes, I agree. It seems that Quicken stores the FID along with the FITID record, and there's some check that fails as a result. Quicken clearly stores the FITID at least, as it will ignore those FITID transactions in subsequent QFX files. This seems to be a case in which it doesn't ignore the transaction, as the FID does not match (at least that's my theory, but it's up to the Quicken team to identify the real reason for the OL-221-A error, and fix it). What I haven't checked yet is whether this issue will also impact direct import (not via QFX dowload/import); I hope it doesn't.
0 -
Quicken definitely stores the FITID of all the transactions, that is how it prevents importing duplicate transactions. But this idea that the FID is included in the storing of FITID just doesn't hold water in my book. OL-221-A usually means a syntax error. That is why I suggested looking at the connection log, because that is where it usually reports them. You might also look at the OFX log.
As for getting Quicken to look at the problem you are going to have to contact Quicken support for that.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
And if I had to take a guess, I would bet the real problem is that there is a syntax error in all the old transactions and that only the financial institution can fix the problem.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
OK, based on your hint I checked the last transaction (STMTTRN element) from the QFX downloaded from the former bank, and the matching transaction from the current bank. Both are syntactically correct. The only difference is the TRNTYPE ("DEBIT" vs "POS") and the FITID (apparently the new bank uses its own FITID, so FID/FITID mismatch is clearly not the issue). There are minor differences in the MEMO and NAME fields (just text differences, nothing invalid). So it appears that there is some other transaction matching going on (e.g. using the time and amount?), or some other bug at work here.
0 -
Did the connect log have anything any it?
Just for reference when I'm trying to find such problems, other than looking at the logs I tend to try tweaking the QFX file entries until I figure out what Quicken doesn't like. Given that you have already said that removing all of the old transactions fixes the problem, I would reintroduce just one and see if you can figure out what in it is causing the problem.
Of course, all of this will only really narrow down the problem, but the true fix would have to come from the financial instituition.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
I downloaded the QFX data directly and imported it. I prefer to use that method as I can then archive the raw QFX data for later use, and I don't have to share my credentials with a 3rd party. The testing approach you mention makes sense, and if I find anything I will share it. I hope though that the Quicken team is watching these comments and investigating. It would really be helpful if there were some acknowlegement that the issue is on their radar, given e.g. in this case the large number of users likely affected.
0 -
The connection log and the OFX log are also used for Web Connect/QFX file importing, they aren't restricted to the automatic downloading of transactions.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
The connection log (thanks) does show lines ala:
20230320 09:28:10: Not all required fields present. Object: STMTTRN missing tag: TRNAMT
The OFX log does not show any specific errors.
The connection log errors started appearing after the bank cutover. I confirmed however using the shell command below, that all STMTTRN elements contain a start and end TRNAMT tag.
ls -t Account*.qfx | while read f; do sed "s~()~\r\n\1~g" "$f" | sed "s~()~$1\r\n~g" | grep "" >tmp.qfx; echo "$f $(grep -c 'STMTTRN' tmp.qfx) $(grep -c -v 'TRNAMT' tmp.qfx) $(grep -c '<TRNAMT' tmp.qfx) $(grep -c '/TRNAMT' tmp.qfx)"; done
Example of the output, for the QFX files since the cutover (fewer overall default STMTTRN records) and the last file before the cutover (more records by default, as provided by the earlier bank):
AccountHistory(23).qfx 72 0 72 72
AccountHistory(10).qfx 3074 0 3074 3074The results are number of STMTTRN records, number of records that do not have TRNAMT tags, and number of open and close TRNAMT tags.
At this point Quicken will need to debug further. If I were to guess, I'd say some other bug is causing the code to mis-parse the STMTTRN records, or some other edge-case bug. But for now I have a (poor) workaround: download only transactions since the cutover.
0
