Generic transaction import
Thu, 6 Jun 2002 20:34:39 -0400
> > -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
const char * gnc_import_get_acc_online_id(Account * account)
is provided for searching. If no account is found with a matching online_id,
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
> > 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?