Generic transaction import

[Benoit Grégoire]

> > -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.  This identifier is stored in a
> > kvp_string with key account_online_id.  The format of this string is
> > bankID/branchID/accountID for a bank account.  If one of these fields
> > isn't present, it is ommited, so for a credit card, we would have
> > //cardnumber.
>
> 1. We have several numbers here (bankID, branchID, accountID) and I wonder
> whether it is a good idea to store them in one string which needs to be
> parsed by anyone who's gonna use it. Couldn't we just add one kvp_string
> for each of the single data fields? i.e. one with key
> account_online_bankid, one with account_online_branchid and so on.
>
> 2. As it turned out in our IRC discussion, the account and bank number
> format is quite different from country to country. So I just suggest to add
> a forth field, "country" to the above mentioned.
> http://www.ecbs.org/iban.htm is a document describing the efforts for an
> International Bank Account Number, IBAN. Even in that IBAN the country code
> (according to ISO-3166) is the very first two digits of the number, so
> obviously it does matter what country the rest of the account
> identification applies to. We can just add a forth kvp_string with key
> account_online_country and values taken from ISO-3166.

After thinking about it, here is the new paragraph:  

-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. 

> > 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 think that would result in a long series of individual
> dialogs, and IIRC in the current QIF importer this was solved differently
> so that the user gets only *one* dialog with all transaction in question
> from the importing process.

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).  What I havent figured out 
is how you add the other splits potentially needed to balance the 
transaction. But I am not much of a UI guy, I just complain a lot about UIs 
;)

> > 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?