Working on MT940 importer

Best, Jan-Pascal van j.p.vanbest at tbm.tudelft.nl
Fri Sep 12 11:46:47 CDT 2003


Hi there,

I've done some work on an MT940 importer, based on the 
dormant Sourceforge project libmt940. At the moment I've 
got a worker parser (using lex and yacc) and some 
rudimentary importer code, borrowed from the ofx importer. 
I'm planning to contribute this back to libmt940 (one more 
external dependency for gnucash!).

A problem I'm encountering is that every bank seems to have
its own ideas about what an MT940 file is supposed to look like.
Especially the "booking code" and the "free field" that my bank
uses are not documented, and I excpect similar problems with
other banks. Oh, and the official documentation is only available
if you're a financial institution and pay a lot. Fortunately,
some banks do publish their mt940 specs and most of them are
quite similar, apart from the above-mentioned fields.

So, my proposal is as follows:
- Ask the libmt940 maintainer for access to the project's CVS (done)
- Ask around (here, on gnucash-users, maybe somewhere else?) for 
  example mt940 files
- Commit the completed parser to libmt940 (the version currently 
  in CVS is incomplete and doesn't have a C API, or any API at all)
- Finish the importer. I'll probably need some help from you on 
  the gnucash core API.

One question to start with: the parser API can be made in a number of ways:
1. With callback functions. You define functions like 
  mt940_start_transaction(), mt940_transaction_memo_field(), 
  mt940_opening_balance(), which get called in a specified order.
2. The parser reads the entire file, turns it into a data structure and
  returns that data structure. Makes for a cleaner and simpler API,
  but may drive up memory requirements if mt940 file being read is large
3. The parser just calls back with every "statement" or transaction.

I think I'll choose the last option, unless you have argument for another choice?

Then there is the problem of supporting the different banking format. 
I've thought of a way to do this cleanly, but it will probably come down
to first filling in the transaction using a default interpreter and then,
for known bank-specific formats, calling functions to do the dirty work.
This means that the bank specialties are hard-coded in the importer module.

Please let me hear your opinions (and get those anonymized MT940 files coming!)

Jan-Pascal


-- 
Jan-Pascal van Best
Delft University of Technology
http://www.tbm.tudelft.nl/webstaf/janb/index.htm 


More information about the gnucash-devel mailing list