Hello everyone,
Just confirming the issue with Citibank QFX files. They are changing the
FITID for the same transactions in the QFX downloads. I'll reach out to
them, but I'm not optimistic
The download on Friday yielded the following for a specific transaction:
CREDIT
2020072112
54.00
Michael,
Exactly. The QFX file only contains the information that the bank would
put on your monthly account statement along with the necessary
infrastructure to identify which bank created the file and which account
and the time frame which the file describes and sometimes some additional
inform
Hello David,
In looking at the QFX file, I only see one side of the transaction. This
file has 3 distinct transactions ( records) that are not related
and only one account ID is listed.
Michael
On Mon, Jul 27, 2020 at 5:56 PM David Carlson
wrote:
> There is another use case which GnuCash also
There is another use case which GnuCash also needs to handle. Some OFX
files may contain both sides of an inter-account transfer between two
accounts within the same bank because the OFX file can include multiple
accounts. In fact, I do that on a regular basis at one of my banks. I do
not test G
Fross, Michael,
Are you trying to match bank payments to credit card accounts from QFX/OFX
downloads from both sides? If so, the FITID's might accidentally match but
the FID and/or BANKID and/or ACCTID of the bank/credit card transaction
split line in the import file should be different from the
Got it. Thanks. Now I understand why it used to work. And I certainly
wouldn't expect GnuCash to correct a bank's horrible behavior. I'll keep
an eye on the FITID and see if that's what they are doing.
Thanks everyone for your help. Much appreciated.
Michael
On Mon, Jul 27, 2020 at 5:13 PM J
Ah, OK I get it now!
Yes, you should check that from one day to the next, the FTID returned
by citibank remains the same (for the same transaction). If not, then
that's going to be a problem.
What has changed recently with GC is that it not will not match a new
imported transaction with one fro
No. Section 3.2.3 of the OFX 1.6 spec:
"An FI (or its Service Provider) assigns an to uniquely identify a
financial transaction
that can appear in an account statement. Its primary purpose is to allow a
client to detect
duplicate responses. Open Financial Exchange intends for use in
statement
Hi Christopher. Alas I do not keep the QFX files. I'll hang on to them
for now and see if the FIDID does change.
On Mon, Jul 27, 2020 at 4:20 PM Christopher Lam
wrote:
> As I understand the ofx spec*, the fitid should be an invariant for the
> bank and account. By any chance do you have older
Hi Jean. Let me try to better explain my issue.
On most days, I download QFX files from my Checking and Credit Card
accounts and import them. In this way I clear transactions and I can see
what's going on. The next day I'll do so again, and the importer skips
those that have already been matche
As I understand the ofx spec*, the fitid should be an invariant for the
bank and account. By any chance do you have older qfx files to compare?
* https://www.ofx.net/downloads.html
On Tue, 28 Jul 2020, 4:34 am Fross, Michael, wrote:
> Thanks Jean / John for your thoughts. There is a register e
There's a misunderstanding here.
This is what GC does:
- It looks at the OFX transaction, which always has an FITID.
- IF GC sees this FITID in one of the register transactions, it skips
the OFX transaction, because it's already been imported (when a
transaction gets imported from the ofx, the o
Thanks Jean / John for your thoughts. There is a register entry that
matches, IMHO, very closely. I increased the Match Display Threshold from
1 to 3, and then to 6 (which appears to be the highest value allowed.)
Every transaction from the import says "Match Missing."
Digging around a bit, for
Ah, forgot about the ID, thanks.
Regards,
Adrien
On 7/27/20 12:31 PM, Jean Laroche wrote:
No,
>> - There's a matching transaction but it's already been matched to an
>> imported transaction at some point so it's not available to be matched
>> to the new imported one.
This means, if you re-i
No,
>> - There's a matching transaction but it's already been matched to an
>> imported transaction at some point so it's not available to be matched
>> to the new imported one.
This means, if you re-import the same file, the register transactions
that were previously imported are marked as havi
This appears to mean that if a subsequent import file contained a
duplicate transaction for some reason, (or the user accidentally
selected an already imported file) then duplicates would be imported. Or
am I reading that wrong?
Regards,
Adrien
On 7/26/20 4:56 PM, jean laroche wrote:
- There
To get a match you have to have a transaction in the register that's
sufficiently similar to the one you're importing, and that has not been
imported/matched before.
In your case, it could be one of these reasons (I can't see the image):
- There's no matching transaction in your register (no exi
If there's no matching transaction already in the account then there's nothing
to clear. In that case only adding or not makes sense.
Regards,
John Ralls
> On Jul 26, 2020, at 1:56 PM, Fross, Michael wrote:
>
> Hello all,
>
> I sent this earlier this month and didn't see any reply so I thoug
Hello all,
I sent this earlier this month and didn't see any reply so I thought I
would try again. Has anyone else seen these issues? I use Citibank and
perhaps it's a Citibank issue, but I did not have this problem on v2 or v3.
Thanks all. I appreciate the help.
Michael
On Sat, Jul 4, 202
Hello all,
I typically download QFX files from my banks every day or two, import them
to clear them in Gnucash. Worked great. However, ever since upgrading to
v4, the importer seems to have trouble matching. Most of the imported
transactions are listed in the importer as (A)dd, but when I selec
20 matches
Mail list logo
