account matching (was: Generic transaction import)

[Christian Stimming]

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