> > -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? _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
