semantics of importer account_id

G. Paul Ziemba pz-gnucash-devel at
Thu Oct 29 23:24:16 EDT 2015

I'd like to highlight [what I claim to be] a design issue with the
way the importer handles onlind IDs, propose two possible solutions,
and solicit further opinions on the validity of these points as
well as alternate ideas/approaches.

Some relevant files for anyone following along:




Different bits of code refer to the account identifier with various
names. gnc_import_select_account() calls it "account_online_id_value."
This identifier is stored as "online_id" in the gnucash xml data file.

The gnucash aqbanking importer constructs an online_id/account_id
as, roughly, bankcode + accountnumber.

The ofx file importer uses the account_id provided by libofx, which
uses various string components among the set {acctid, acctkey,
brokerid, bankid, branchid} depending on the account type. Libofx
also seems to provide functions to access these individual components.

In current (2.6.9 and earlier) gnucash, there can be an "online_id"
associated with a gnucash account. I believe there can not be more than
one online_id for a given gnucash account. In the typical scenario,
when a user does the initial import of online/file data import to
an account, the gnucash account's online_id value is set to whatever
account_id string has been set by the import code.

Here is the problem:

If a user wants to import transactions for an account by an import
method that is different from what he originally used, the online_id
generated by the new import method will almost certainly be a different
format than what was set before (although there will probably be
some identical substrings). Consequently, the new data won't match
the proper account. Worse, it risks resetting the gnucash account's
online_id and breaking the matching for the previous import method.

In my case, I usually use aqbanking to get transaction data
for an account, but the bank provides only 90 days of history.
I can get older data in the form of an OFX file.

Some possible solutions:

1. Extend the gnucash account schema to allow multiple online_id
   fields, one for each import method. Each import method would
   need to be named with some standard string.

   I prefer this solution (decoupling), because it allows each
   import method some flexibility in identifying accounts. I am
   willing to attempt a patch.

2. Require each import method to generate its online_id in the
   same way. This would mean no changes to the gnucash schema.
   Libofx appears to provide accessors to the necessary individual
   identifier strings. However, I think this approach is fragile
   and risks future problems if a component field is unavailable
   in some future transaction data format.

Are there other opinions/solutions? 
G. Paul Ziemba
FreeBSD unix:
11:46PM  up 66 days,  2:38, 32 users, load averages: 0.97, 1.14, 1.09

More information about the gnucash-devel mailing list