semantics of importer account_id

David Carlson david.carlson.417 at gmail.com
Tue Nov 3 15:50:04 EST 2015


On 10/31/2015 10:33 AM, G. Paul Ziemba wrote:
> I believe (I could be wrong, though) that the QIF importer does not
> match against any online_id associated with the gnucash account, so
> importing from QIF wouldn't modify the stored online_id.
>
> The problem occurs for me going between online OFX via aqbanking
> and file OFX via libofx.
>
> cheers,
>
>   ~!paul
>
>
> On Fri, Oct 30, 2015 at 07:11:42AM -0700, David Carlson wrote:
>> I have used both QIF and OFX imports interchangeably on the same account
>> without problems.  I am not a computer programmer, but I don't see the
>> problem.
>>
>> David C
>>
>> On Thu, Oct 29, 2015 at 8:24 PM, G. Paul Ziemba <pz-gnucash-devel at ziemba.us>
>> wrote:
>>
>>> 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:
>>>
>>>      gnucash/src/import-export/generic-import-design.txt
>>>      gnucash/src/import-export/import-account-matcher.c
>>>      gnucash/src/import-export/aqb/gnc-ab-utils.c
>>>      gnucash/src/import-export/ofx/gnc-ofx-import.c
>>>
>>>      libofx/lib/ofx_container_account.cpp
>>>          OfxAccountContainer::gen_account_id(void)
>>>
>>>      aqbanking/src/libs/aqbanking/imexporter.[ch]
>>>
>>> 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
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>

Sorry, it seems that my smartphone is not so smart, and I failed to 
address my reply properly to either of the GnuCash lists.  I think that 
the correct list may be the user list, but I will direct this to both.

I think the account IDs should be the same ones generated by the 
Financial Institution regardless of the client software used to acquire 
and interpret the OFX file, so that suggests to me that there is a bug 
in one of the methods you are using.  Perhaps a developer can help with 
this.

David C


More information about the gnucash-user mailing list