Generic transaction import
Christian Stimming
stimming@tuhh.de
Fri, 7 Jun 2002 01:40:22 +0200
-----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-----