Message: 5 Date: Sun, 24 May 2020 00:19:33 -0400 From: "Alan" <alang...@bigtowers.net> To: "'Gnucash Users'" <gnucash-user@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 _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
