New Module: FinTS-Banking | Standard German (and Austrian?) Banking Protokoll

43 views
Skip to first unread message

Richard Martin

unread,
Jan 17, 2018, 11:03:24 AM1/17/18
to tryton-contrib
Hallo,

we developed a FinTS-Banking-Modul (FinTS=FinancialTransactionServices) for Tryton 4.6.

I don't know whether FinTS is more of a German-specific banking protocol. But in Germany it will work (as a standard) with most of the banks.

Feedback is very much appreciated.

Regards,
Richard Martin (Teltow/Berlin)

Download:
https://pypi.python.org/pypi/mds-account-statement-fints

Limitations:
PIN/TAN authentication only
read only access

Requirements:
Tryton 4.6
fints (tested with 0.2.1)
Python 3

Banks tested:
DKB, Postbank, Deutsche Bank, Sparkasse

Cédric Krier

unread,
Jan 17, 2018, 11:45:05 AM1/17/18
to tryton-contrib
On 2018-01-17 07:45, 'Richard Martin' via tryton-contrib wrote:
> Hallo,
>
> we developed a FinTS-Banking-Modul (FinTS=FinancialTransactionServices) for Tryton 4.6.
>
> I don't know whether FinTS is more of a German-specific banking protocol. But in Germany it will work (as a standard) with most of the banks.
>
> Feedback is very much appreciated.

Why not using the generic import wizard of the module account_statement?

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

Richard Martin

unread,
Jan 17, 2018, 6:35:09 PM1/17/18
to tryton-contrib
> Why not using the generic import wizard of the module account_statement?

As we see the generic import wizard is supposed to be used with files (with CODA-filter). We need a filter for 'mt940'. So we would have to make changes to the generic wizard. We didn't want to do that. So we compromised on building a new wizard.

If you have a hint for an elegant way to combine our import and filter with the generic wizard (and still keeping its existing functionality), we would be happy.

R.

Cédric Krier

unread,
Jan 18, 2018, 4:10:04 AM1/18/18
to tryton-contrib
On 2018-01-17 13:34, 'Richard Martin' via tryton-contrib wrote:
> > Why not using the generic import wizard of the module account_statement?
>
> As we see the generic import wizard is supposed to be used with files
> (with CODA-filter). We need a filter for 'mt940'.

B2CK has written a library to parse mt940: https://mt940.b2ck.com/
And I'm pretty sure, soon we will have to submit a module
account_statement_mt940.

> So we would have to make changes to the generic wizard. We didn't want
> to do that. So we compromised on building a new wizard.

But the wizard is there to receive extension to support any statement
format.

> If you have a hint for an elegant way to combine our import and filter
> with the generic wizard (and still keeping its existing
> functionality), we would be happy.

The only issue, I see, is to get the file on the wizard when it was
downloaded on the server-side. I see two options:

- have a new model that store the file and run the wizard on it
(which will make it use the file automatically)

- have an option on the wizard start that adds a transition which
download the file

I think the first option can be a standard solution implemented in
account_statement.

Cédric Krier

unread,
Jan 18, 2018, 4:55:05 AM1/18/18
to tryton-contrib
Some more thoughts. What about a desktop application that will use
proteus to run the import statement wizard in background.
I mean for now you must enter the PIN in a wizard that send it to the
server which means that it is at some point stored in the database. And
this is not very nice for the security.
Bu if you have a local application that does the job to fetch the
statement and then run the wizard in background (it can open the
imported statement using the URI schema), the PIN will stay on only
between the user computer and the bank.

Richard Martin

unread,
Jan 18, 2018, 10:28:53 AM1/18/18
to tryton-contrib
> Some more thoughts. What about a desktop application that will use
> proteus to run the import statement wizard in background.
> I mean for now you must enter the PIN in a wizard that send it to the
> server which means that it is at some point stored in the database. And
> this is not very nice for the security.
> Bu if you have a local application that does the job to fetch the
> statement and then run the wizard in background (it can open the
> imported statement using the URI schema), the PIN will stay on only
> between the user computer and the bank.
>
The PIN doesn't have to be stored in the DB. If you don't store it, you'll put it in for each request/session to the bank (as we do). This works fine.

Your proposal for a solution with proteus sounds good. We haven't used proteus jet. And (right now) the security issue (see above) is not driving us to go this way.

Thx again,
Richard

Richard Martin

unread,
Jan 18, 2018, 10:28:53 AM1/18/18
to tryton-contrib
Am Donnerstag, 18. Januar 2018 10:10:04 UTC+1 schrieb Cédric Krier:

> And I'm pretty sure, soon we will have to submit a module
> account_statement_mt940.
>
This would be great.
>
> But the wizard is there to receive extension to support any statement
> format.
>
We were not as familiar with this point/wizard.
>
> The only issue, I see, is to get the file on the wizard when it was
> downloaded on the server-side. I see two options:
>
> - have a new model that store the file and run the wizard on it
> (which will make it use the file automatically)
>
> - have an option on the wizard start that adds a transition which
> download the file
>
> I think the first option can be a standard solution implemented in
> account_statement.
>
We will work on this. I'm sure we will make a new approach the next weeks.

Thank you for your thoughts and advise.
Richard

Cédric Krier

unread,
Jan 18, 2018, 11:15:05 AM1/18/18
to tryton-contrib
On 2018-01-18 07:11, 'Richard Martin' via tryton-contrib wrote:
> > Some more thoughts. What about a desktop application that will use
> > proteus to run the import statement wizard in background.
> > I mean for now you must enter the PIN in a wizard that send it to the
> > server which means that it is at some point stored in the database. And
> > this is not very nice for the security.
> > Bu if you have a local application that does the job to fetch the
> > statement and then run the wizard in background (it can open the
> > imported statement using the URI schema), the PIN will stay on only
> > between the user computer and the bank.
> >
> The PIN doesn't have to be stored in the DB. If you don't store it,
> you'll put it in for each request/session to the bank (as we do). This
> works fine.

Any value entered on a wizard form is stored in the database during the
session of the wizard.

Richard Martin

unread,
Jan 19, 2018, 5:15:21 PM1/19/18
to tryton-contrib
> Any value entered on a wizard form is stored in the database during the
> session of the wizard.

Good to know and be aware of it!

Thx
R.

E Boer

unread,
Mar 10, 2018, 6:35:06 AM3/10/18
to tryton-contrib
On Thursday, 18 January 2018 10:10:04 UTC+1, Cédric Krier wrote:
> B2CK has written a library to parse mt940: https://mt940.b2ck.com/
> And I'm pretty sure, soon we will have to submit a module
> account_statement_mt940.

We are moving to 4.6 and want to import mt940 statements. Is the account_statement_mt940 already made? Otherwise we will take the account_statement_coda and change the code so it will import mt940 statements.

Cédric Krier

unread,
Mar 10, 2018, 7:10:04 AM3/10/18
to tryton-contrib
Indeed we have not yet receive any request for it.
But if you work on it, please try to submit it to be a standard module:
http://www.tryton.org/how-to-contribute.html
Reply all
Reply to author
Forward
0 new messages