Working on MT940 importer

[Christian Stimming]

Thanks a lot for working on this topic. However, there has already been 
some discussion about this topic in early July, see e.g. 
http://article.gmane.org/gmane.comp.gnome.apps.gnucash.devel/9454
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.


Christian


> 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
> 
>