-----BEGIN PGP SIGNED MESSAGE----- On Samstag, 8. Juni 2002 21:17, Benoit Gr�goire wrote: > The one important purpose of this string is to allow account matching. It > is passed to gnc_import_select_account, wich is a function provided by the > generic infrastructure. It does a simple string compare on this string. > All we have to do is both write this string in a way (not necessarly a > COMMON way) that is as unambiguous as our online system allows. We should > also try to keep-in a human-readable format, so It can be displayed to the > user. (i.e: merely concatenating all the numbers is probably a bad idea. > The string can be parsed if you want, but it isn't MEANT to be parsed, only > compared. And comparing four strings everytime, instead of generating one > once, seems uselessly inefficient, and would add three parameters to the > function. > > Account * gnc_import_select_account(char * account_online_id_value) is > provided by the generic module and called by the online system specific > modules. const char * gnc_import_get_acc_online_id(Account * account) is > provided by the generic module and registered in gnucash's query > infrastructure, then used by the generic module. > > I hope it is clearer.
Ah yes, now I understand. These two functions, together with the account_online_id string in your proposed format is used for finding the right account to do import the transactions into. Now the point in HBCI is that I *always* know already the Account* where the transactions are going to be imported into. From HBCI, the order of actions upon transaction importing is the following: 1. Identify that a particular account has a real-world counterpart accessible with HBCI, therefore present the user a GUI button "Download transactions for this account by HBCI" 2. If that button is pressed, some passphrase is asked by the user, network connection is opened, a list of transactions is downloaded, network connection is closed (all using the OpenHBCI API). 3. Now find and eliminate transaction downloaded twice in the source account (i.e. the account in which context the above button was pressed). -- your bullet number two. 4. Find destination account(s), and find the matching transactions there if they exist. -- your bullet number three. I.e. the step "find the source account" is unnecessary for HBCI, since we already have gnucash's Account* from step number 2. Therefore I wouldn't even need the account_online_id string for HBCI at all. I would probably just leave that string empty for a HBCI-enabled account. You can safely ignore my previous complaints about its format. :-) Nevertheless I would suggest storing the country code in that string, too, like "country_id/bank_id/branch_id/account_id". We could take the three-letter country codes from ISO-3166 for that. Btw did you write something more about the step 4 above (find destination account)? I didn't find it in your first draft. I guess this should happen in the same way as in the current QIF-Import. I get a multi-column dialog with columns "transaction; destination account". It suggests destination accounts in the same way as the auto-completion feature in the register, i.e. based on the most-recent entered transaction with a matching description text. If there is no matching transaction, the transaction gets booked to a default destination account "Unknown something" IIRC. I think this would be a good way to follow. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPQMyM2XAi+BfhivFAQF9wQP+J6EEvS9nQXbITHeRfJjkRRGHcs9IES/l Rq7pauGNWG4in94vY2nvMe+TaNq81QcTGtlR5fbl/GAXoaWiB11BoPLQwr+yxlOn kd6dOuIFmN1KhYW1AKQOpU247RsTbaqiCXdwXGdFPW2aG8+4Hbv1coZwlLwB0VoH zXwJB0xXY5I= =69xj -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
