Generic transaction import; country code question

[Benoit Grégoire]

On June 7, 2002 06:16 pm, Christian Stimming wrote:
> On Freitag, 7. Juni 2002 02:34, Benoit Grégoire wrote:
> > -Identifying and if necessary creating the source account:  The account
> > is identified using the account number for ofx and HBCI, and the account
> > description for qif, if available.  The account number or identifier is
> > stored in a kvp_string with key account_online_id.  The online system can
> > use and format this frame however it sees fit, but it must be a
> > kvp_string. A function:
> > const char * gnc_import_get_acc_online_id(Account * account)
> > is provided for searching.  If no account is found with a matching
> > online_id, the function:
> > Account * gnc_import_select_account(char * account_online_id_value)
> > must be called.  The user can then select an existing account from a list
> > (the current account_online_id are displayed alongside the accounts), or
> > create a new one.  The account_online_id is then stored in the selected
> > or created account's kvp_frame.
>
> I'm still not quite convinced about whether having *one string* as an
> online_id is really a good idea. The online banking code would need to
> parse that string each time it is used -- this may be feasible, but is it
> really necessary? AFAIK we *can* identify an account worldwide by *four*
> string where some might be empty: country_id, bank_id, branch_id,
> account_id. The point is, if we store *four* strings instead of one (plus
> another pointing to the respective online-banking protocol) then I have
> *all* information that I need for running HBCI with that account.
> (branch_id will be empty in Germany, but that shouldn't be a problem.) And
> I won't be running into any problems with string parsing. The
> account-matching code would be comparing four string in the abovementioned
> order instead of one string, but IMHO that shouldn't be a problem.

The one important purpose of this string is to allow account matching.  It is 
passed to gnc_import_select_account, wich is a function provided by the 
generic infrastructure.  It does a simple string compare on this string.  All 
we have to do is both write this string in a way (not necessarly a COMMON 
way) that is as unambiguous as our online system allows.  We should also try 
to keep-in a human-readable format, so It can be displayed to the user. (i.e: 
merely concatenating all the numbers is probably a bad idea.  The string can 
be parsed if you want, but it isn't MEANT to be parsed, only compared.  And 
comparing four strings everytime, instead of generating one once, seems 
uselessly inefficient, and would add three parameters to the function.

> In your re-worded paragraph above I didn't quite get the meaning of the two
> new functions. Who will provide each function, and who will use it? But the
> idea to have those functions seems to be good.

Account * gnc_import_select_account(char * account_online_id_value) is 
provided by the generic module and called by the online system specific 
modules.  const char * gnc_import_get_acc_online_id(Account * account) is 
provided by the generic module and registered in gnucash's query 
infrastructure, then used by the generic module.

I hope it is clearer.

-- 
Benoit Grégoire
LibOFX http://step.polymtl.ca/~bock/libofx/