Working on MT940 importer
Christian Stimming
stimming at tuhh.de
Tue Sep 16 18:33:09 CDT 2003
Dear Jan-Pascal,
Best, Jan-Pascal van schrieb:
> The importer now can import my mt940 files.
Very nice :-). I'll have a closer look when I have time at home, which
may be the case tonight or tomorrow night. If I don't stumble over any
problems, I will commit your changes to CVS. By the way, did you create
your patch against CVS HEAD branch or the gnucash-1-8-branch?
> The actual importer
> core is quite simple: it just calls HBCI_SWIFTparser_readMT940()
> repeatedly, and then uses list_HBCI_Transaction_foreach() with
> a callback function based on the one from gnc-hbci-gettrans.c.
Great to hear that it worked :-)
> I guess we should split off the part from trans_list_cb() that
> get the gnucash account from the part that does the actual
> importing, to reduce code duplication.
Sure. Sounds good. I'll have a look at the patch.
> One other thing: the swift parser in openhbci is incorrect for the
> case that the account id in :25: does not contain a '/'. It should
> return the entire string in "id" while leaving "instCode" empty,
> like this:
>
> pos=0;
> bool found_inst=false;
> // first read the institute code (BLZ)
> while(pos<tc.length()) {
> if (tc.at(pos)=='/'){
> // store our institute code
> instCode=tc.substr(0,pos);
> found_inst=true;
> break;
> } // if
> pos++;
> } // while
>
> if(!found_inst)
> pos=0;
> else {
> // then read the account id
> pos++; // skip "/"
> if (pos>=tc.length())
> // no id
> return false;
> }
> id=tc.substr(pos);
> return true;
Err... could you post a diff to openhbci-general? I can't immediately
tell whether changes here are possible without breaking anything. But I
guess your reasoning sounds good.
> By the way, why isn't string.find() used here?
In the old days when this part was written IIRC the programmers still
felt uneasy about the whole STL and its methods... I guess today this
would be written with string::find.
>>[booking code]
>
>>I've observed the same thing with one of my banks. However,
>>my other bank uses 999 for any transaction statement, so in
>>this case the code is kinda' useless.
>
> Is there a way to handle "special cases" like this in the code? It would
> probably mean that the parser needs to act differently depending on the
> bank that issued the mt940 data.
I don't really understand. Where is it that the parser needs to act
differently? In any case that would require some major changes in the
parser, which are probably not encouraged... In another library I saw
that those "special bank cases" are handled by something like a
pre-parser which only eliminated those bank weirdnesses, but the actual
parsing was done bank-independently.
> By the way, I tried the make-gnucash-patch script which created a
> multi-megabyte diff, so I'm attaching only the files in
> src/import-export/mt940. There are some other changes to be made,
> for instance in configure.in and in (I think) src/scm/main.scm, but
> they are montly trivial.
>
> What do you think?
Sounds very good. Obviously you now submitted a patch. I'll check later
today or maybe tomorrow.
Christian
More information about the gnucash-devel
mailing list