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).
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.
SYNC TRYTON ACCOUNTING WITH BANK ACCOUNT (camt.053)
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:
EXCHANGE FILES WITH BANK (EBICS)
Further on, these XML Files should be transferred between the bank and tryton. Cedric already wrote some code for that as it looks like:
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:
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
Testing environments is no problem. In the meantime, I had various talks with banks and postfinance and we can get test environments from them. https://www.six-interbank-clearing.com ist the company (daughter of the swiss banks federation) which cares about all that testing.
What do you mean?
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.
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?
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.
I previously worked on the messaging technologies within UBS and I may be able to offer some support for this effort. Has anybody already made any progress on it? How much demand is there from users who have Tryton or want to adopt it?
Dear Daniel
Virtual Things integrated SEPA including this “swiss layer” for the common payment reference number “ESR”. Pain.001 is working and also camt.053. With pain.008 we integrated it and we are in a test-project where “the customer is on it”. So far so good.
EBICS would be a great idea and we’d like to have it, but I have no idea about potential costs for it. So if you have a clou how to integrate it and what a budget could be, I was very happy.
or the camt.53 documentation from six.