SEPA & EBICS eBanking Integration

(Stefan Vogel) #1

Dear all
We actually would like to integrate eBanking into tryton and I saw code snippets for different tasks. I write this topic with the idea to have an overview on the subtasks and try to encourage your bringing eBanking to fly in tryton.

There is a SEPA Module for tryton existing that can produce some SEPA-Standard-XML-ePayment files (eg. pain.001 to pay the supplier and pain.008 to get money from a customer with debit direct and camt.053 to get info about the moves on my bank account).


Here, we need to extend it for Switzerland. In general, we use pain.001.001.03, which is existing in tryton 4.0 we use. In depth, the banking industry extended that flavour to with some more payment types
We need somebody, who extends the tryton-standard-flavour to, see

DEBIT DIRECT (pain.008)
Pain.008 we plan to do later an but we have a customer who is interested in using pain.008 in germany. So if there is anybody out there who could the existing tryton-standard, feel free contacting me.

On the other hand, the paid invoices need to be imported into tryton and the bank account then should get “synchronized” with the accounting bank account in tryton.

For that task, one can get a camt.053 XML file from the bank and import it into tryton.
Then, tryton can read out all account moves on the bank account und check the accounting bank account in tryton, weather the same moves exist. If they do not exist it would be a nice idea to immediately be able to link a accounting journal to that moove and then tryton produces the corresponding accounting record.
Also for this case, I found two existing projects for tryton:
In Switzerland, we have an extended flavour for camt.053, see
Could we motivate that team making a final tryton module out of it? What would it cost?

Further on, these XML Files should be transferred between the bank and tryton. Cedric already wrote some code for that as it looks like:
Could we motivate Cedric to make a final tryton module out of it? What would it cost?

Hope my writing is ok like this. It is my first topic.
All the best, Stefan

(Cédric Krier) #2

I do not see by “more payment types”. I think it is better to try as much as possible to get account_payment_sepa modules flexible enough to work on most of the country. We have account_payment_sepa_cfonb because it was really not possible to do other way.

This is not how Tryton works. If the user want to create accounting move before receiving the bank statement, he must use the account_payment_clearing module. So there should never be duplicates moves to be reconciled.

issue4658 has been stalling for 3 years now. And it would require a complete redesign to follow the issue5882.

I stopped working on it. It is quite difficult because we could not find a testing service. (And our customer dropped the requirement).
It is probably cheaper and faster to use services like:

(Stefan Vogel) #3

No problem. Let’s integrate that. It not more than some variants on a B-Layer of XML file. For example we send your invoices with a code (called ESR) to the customers. It inherits the bank where to send the money and the invoice number ant the amount so the issuer of the invoice then can import a file with the payment and automatically can match the payments to an invoice and set it to the paid status in tryton.

I’m not sure weather we understand each other. I’m not a developer, you must know. I just read about account_payment_clearing in the doc on the repository. The bank statement (camt.053) would be imported first as existing in tryton. Then the payment and account moves are done. Also as existing in tryton.

But after all that, most likely, the bank account still won’t be in sync with the corresponding account in tryton and it takes a lot of time to bring it in sync. The request is to let the user (or tryton by learning) easily execute an account move by selecting a suitable journal describing what the amount on the bank statement is about (e.g. rent, wages, banker’s orders, kick-backs, …).

Good point to take such a service, but they do not support such special flavours the the discussed standards. Payment automation has become a central subject in business and needs certain flexibility that we could cover with tryton in the different countries. So I focus on motivating you on reengaging with the project :slight_smile:

Testing environments is no problem. In the meantime, I had various talks with banks and postfinance and we can get test environments from them. ist the company (daughter of the swiss banks federation) which cares about all that testing.
What do you mean?

(Cédric Krier) #4

What is B-Layer?

Do you mean an “EndToEndId”?

This is already what the statement does.

(Stefan Vogel) #5

Sorry, I meant the C-level. As much as I know, the XML file is built up hierarchically. There are several levels in depth.
— A Header and description of the transaction
------ B Sum of the payments
--------- C Level with invoice data

In this third level, the ESR-Data needs to be implemented.

ESR comes from “Einzahlungsschein mit Referenznummer”). Check out (in german :wink: or the camt.53 documentation from six.

Cool. So I ask Udo Spallek to integrate it on our instance and we “only” need the integration of camt.053. Do you know more about the status there?

(Cédric Krier) #6

I wrote the XML template and I do not know about such naming convention.
Could you point to an example?

So for me, it is an “EndToEndId”.

It is stalling:

(Stefan Vogel) #7

Yes, you’re right.

(Stefan Vogel) #8

Here also a pain.001 example:

(Cédric Krier) #9

Too bad the Switzerland has created one more format instead of reusing the standard SEPA. So it seems it will require to have a specific module like the account_payment_sepa_cfonb.

There is also this proprietary library: