After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704183 - ofx file import tries to match online_id against ACCTID[space]ACCTKEY even when ACCTKEY is empty
ofx file import tries to match online_id against ACCTID[space]ACCTKEY even wh...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Import - OFX
2.4.x
Other FreeBSD
: Normal normal
: ---
Assigned To: gnucash-import-maint
gnucash-import-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-14 05:24 UTC by G. Paul Ziemba
Modified: 2018-06-29 23:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch account search to look again without trailing space (1.28 KB, patch)
2013-07-14 05:24 UTC, G. Paul Ziemba
accepted-commit_now Details | Review
updated patch (1.79 KB, patch)
2013-07-18 10:27 UTC, G. Paul Ziemba
committed Details | Review

Description G. Paul Ziemba 2013-07-14 05:24:52 UTC
Created attachment 249098 [details] [review]
patch account search to look again without trailing space

I have done many "Actions>Online Actions>Get Transactions" operations for an assortment of bank accounts and credit card accounts via OFX, and expect to continue doing so. (Aside: I use this method to determine which transactions have cleared and to fill in any I might have missed entering manually.) Consequently, for each of these gnucash accounts, there is an online_id value that corresponds to the ACCTID value in the online OFX responses which I would like to continue to use.

The gnucash model (at least in 2.4.X) is that a gnucash account may have at most one online_id value. Therefore, to perform OFX imports of transactions, all imports intended for a given account must match the same online_id.

Recently I began to scan and OCR my paper receipts, and then parse them to generate OFX records representing the transactions. This process will partially replace my manual entry of credit card transactions. I discovered that libofx (0.9.5), which is used for OFX file import, but not for online OFX import, produces an account id equivalent to ACCTID + space + ACCTKEY. In the case where ACCTKEY is empty, the account id is ACCTID + space.

As an example, I have a credit card account "nnnnnnnnnnnnnnnn". The online OFX data returned by the bank has <ACCTID>nnnnnnnnnnnnnnnn</ACCTID>. Gnucash has online_id for the account set to "nnnnnnnnnnnnnnnn". This works fine for online OFX - the account is matched properly upon import.

Now I build an OFX file based on my receipts. It also has <ACCTID>nnnnnnnnnnnnnnnn</ACCTID> and no ACCTKEY. When gnucash tries to import it, it calls libofx to parse the file. But libofx returns an account ID of "nnnnnnnnnnnnnnnn ", which of course does not match the account's online_id because it has a trailing space.

In order to avoid breaking the matching for any existing online_id values in users' data, I decided against changing either the libofx account ID algorithm or the aqbanking ofx algorithm. I do not know enough about the problem space to judge which is the correct approach. Maybe someone else understands if one algorithm should be changed to match the other, or if there is a third, better algorithm that they both should use.

My patch alters the gnucash account matching code to search a second time if the original search fails and the account ID has a trailing space. The second search tries with the trailing space removed.
Comment 1 Christian Stimming 2013-07-14 18:40:19 UTC
Comment on attachment 249098 [details] [review]
patch account search to look again without trailing space

Ok, I understand the problem. It boils down to an unexpected additional space character in the output of libofx vs. the output of libaqbanking. The patch is fine to fix this via this workaround on the gnucash side. I would suggest two minor (cosmetical) improvements in the code: Firstly, please add a comment in the code that explains why the extra space at the end is the leftover from the unexpected libofx processing. Secondly, the g_free(trimmed) should go out of the if-clause for clarity: g_free(NULL) is allowed and does nothing, but forgetting the g_free is bad and because of this a human reader of the code will (hopefully) automatically look for the g_free belonging to the g_strndup.

If I have time during the next days to commit, I'll add those changes myself.
Comment 2 G. Paul Ziemba 2013-07-18 10:27:59 UTC
Created attachment 249484 [details] [review]
updated patch

Added comment describing change; moved g_free outside conditional.
Comment 3 John Ralls 2013-08-02 17:58:10 UTC
Comment on attachment 249484 [details] [review]
updated patch

r23114/5
Comment 4 John Ralls 2017-09-24 22:41:30 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 5 John Ralls 2018-06-29 23:17:23 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=704183. Please update any external references or bookmarks.