Working on MT940 importer
stimming at tuhh.de
Fri Sep 12 12:01:52 CDT 2003
Thanks a lot for working on this topic. However, there has already been
some discussion about this topic in early July, see e.g.
Have you seen those emails, especially my remark about an existing mt940
parser inside the OpenHBCI library?
Best, Jan-Pascal van schrieb:
> 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.
This kind of API is not encouraged in gnucash and should not be used.
> 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
This is the kind of API that e.g. OpenHBCI offers. I would recommend
this kind of API for any external stand-alone library.
> 3. The parser just calls back with every "statement" or transaction.
The *parser* calls back? I.e. the external library calls a callback
function? This would require callback functions just as proposal 1.
does. I would not encourage such an API as well, but I might have
misunderstood what this actually means.
> 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!)
More information about the gnucash-devel