-----BEGIN PGP SIGNED MESSAGE----- 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. 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. > ... > 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 :-) Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPP/y5mXAi+BfhivFAQEtrgP+NOoZw06PSPMjbKorhAeH5D+ML5uwBXzu eEi8tD8AJ+uc947XNgIVPmRW465J7MBGSlHk1UCLckO/pjfc6CeW5kJCNyQTKyMi A/S8JrVYZTnQklyGHjI7yn9SmFu7fSK4sFMEMG8CgW9ncoTbNHPHhlUkU0tKlzr7 u0gWQ4jsJBo= =Jq5k -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
