[GNC] AQbanking Amex OFX Download Badly Broken

Chris Good goodchris96 at gmail.com
Sun May 24 20:40:12 EDT 2020


Message: 5
Date: Sun, 24 May 2020 00:19:33 -0400
From: "Alan" <alangnuc at bigtowers.net>
To: "'Gnucash Users'" <gnucash-user at gnucash.org>
Subject: [GNC] AQbanking Amex OFX Download Badly Broken
Message-ID: <0fbc01d63182$87ba6ea0$972f4be0$@bigtowers.net>
Content-Type: text/plain;	charset="us-ascii"

Tried the Aqbanking section on GnuCash 3.10 with my Amex account. It was
encouraging to see the latest version of Aqbanking now recognizes the
content in the OFX download (last broken version could only read the
headers). Was about to congratulate the development team, but then I noticed
something very wrong with the few hundred transactions I had just loaded
into GnuCash.

None of the payees matched anything that could be matched up with any
previously entered, downloaded and audited transactions. Closer inspection
revealed something very wrong, and repeated on every transaction record
downloaded.

I compared individual transactions in my Aqbanking debug log to the ones
that GnuCash had downloaded. GnuCash apparently concatenated each memo field
followed by a space, followed by the transaction payee name. None of the
downloaded data ended up in a valid transaction memo field. This is badly
broken, and totally unusable.

I examined the debug log to see how well Aqbanking has been communicating
with the bank. Headers show the session established and completed properly.
Transaction records and fields were being presented correctly, amounts were
correctly associated with the real payees, and Amex was proving a fully
formed payee name <NAME> followed by a fully formed memo field <MEMO>. The
transaction ID number was also transferred consistently in the <REFNUM>
field, though GnuCash appears to be ignoring it.

Someone had to go to a lot of trouble to do this, rather than just place
each usable transaction field data into the closest matching ledger fields
(even the transaction ID can be useful for simple dupe checking). That's all
that we're looking for. Download the data, populate the record fields, and
get back to business.

So I'm at a total loss how anyone could have deliberately taken clearly
defined fields and data (that should easily match the "Description" and
"Notes" fields within GnuCash account ledgers), and pretty much destroy
them, along with the user data sets that also have to be deleted and
recreated.

Hi Alan,

I import downloaded .ofx files, as my bank doesn't offer direct connection,
but I think GnuCash does the same thing with direct connect as importing a
downloaded .ofx file.

I believe (but this is just my idea) the <MEMO> fields are imported into the
transaction Note field (View, Double Line) in order to not override the
split Memo fields on existing transactions.

The transaction ID number, if this is supposed to be the unique code for a
transaction in an account, should be in an 'FITID' tag.

The OFX libraries (libofx) were probably not designed for GnuCash, so we
have to map as best we can.

It may be worthwhile creating an enhancement type bug specifying how you'd
like 'REFNUM' handled.

Regards, Chris Good



More information about the gnucash-user mailing list