Generic transaction import

Christian Stimming
Fri, 7 Jun 2002 01:40:22 +0200


On Freitag, 7. Juni 2002 00:24, Benoit Grégoire wrote:
> As I discussed with several people on #gnucash, this is the draft of my
> design document for a generic import.  

General comment: This is a very good and well-thought proposal.

I have some comments from the HBCI point of view.

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

> ...

> The generic module receives the Transaction for the online system specific
> module using function:
> void gnc_import_add_trans(TRansaction *trans);
> Here is the pseudocode of the gnc_import_add_trans function):
> ...
> 	if amount match
> ...
> 		else
> 			add to matches using UNLIKELY
> 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. 

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

Ok, I better get some sleep now :-)

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see