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.
>>this case the code is kinda' useless.[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
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
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
