Generic transaction import; country code question

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----

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.

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.

A word about country codes: I was surprised about you mentioning ISO-3166, but 
this is in fact also what HBCI claims to use. The only thing is that Germany 
switched its numerical country code in 1990, i.e. with the reunion of east 
and west Germany. They switched from 280 to 276. But the HBCI spec says that 
almost all financial software is still using the 280 code, so HBCI is also 
still using it :-) . More on the country codes, including the withdrawn ones: 
http://www.davros.org/misc/iso3166.html 

And again, to give people a flavor about the variety of account identifying 
numbers, I recommend http://www.ecbs.org/iban.htm#Introduction some 
documentation about the introduction of the International Bank Account 
Number.

> > > Present the list of matches to the user in decreasing order of
> > > likelyhood. User has the option of selecting one of the match or
> > > creating a new transaction.
> >
> > Err, do you intend to present a list of matches for each transaction
> > individually? 
>
> I was thinking more about a two pane dialog.  The first pane lists the
> downloaded transaction, you click a transaction in the first pane and the
> second pane shows the potential matches (or new).  

A pane dialog would be totally fine (and I think that's how it is currently 
implemented for QIF).

> > > Remarks and things to remember:
> > > -void gnc_import_add_trans(Transaction *trans) should return as soon as
> > > possible (BEFORE user interaction) so that for systems that maintain a
> > > connection (such as HBCI) the user won't run into timeouts.
> >
> > You don't have to worry about HBCI here -- the network connections will
> > be handeled asynchronous (no, not by jsled :) and if we get to the point
> > of transaction importing, then all connections have long been closed.
>
> Great, but is the calling convention fine for you?

Yes, I think so.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBPQEwoWXAi+BfhivFAQFD0QQAg5oND1WAzQgMMqTQLPispNaPJJrELCBR
lB2rGZcyqfn+AYL17beJPkqDK7WxnYAj1XjSH2eAS78pRms0Bf+KpEzsG1hfNQ+Q
THuVvfimEC6CikSFBEytHLMGA3sGRsffGFBuWkWK09xyWCeeb5xSxK5F2Pq55NmW
DIVQOTo2eqk=
=X7Q7
-----END PGP SIGNATURE-----