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