GNOME Bugzilla – Bug 704183
ofx file import tries to match online_id against ACCTID[space]ACCTKEY even when ACCTKEY is empty
Last modified: 2018-06-29 23:17:23 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 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.
Created attachment 249484 [details] [review] updated patch Added comment describing change; moved g_free outside conditional.
Comment on attachment 249484 [details] [review] updated patch r23114/5
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
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.