2 of them are using UBL as exchange format for the outgoing and incoming invoices.
And Billit has its own JSON format (from which, I guess, they convert into UBL (or any other allowed format by Peppol)) but also support SFTP. (I do not think the API is great because they recompute the taxes.)
So I think that adding support for Peppol should be done first by creating a edocument_ubl and document_incoming_ubl which support the Invoice document.
After that the connection to specific providers will be just about implemented the submission and webhook routes and authentication.
I think it will be good to have options for the service providers (as we have already for the carriers).
I think this is a really nice addition, but Tryton lacks the import and export of UBL documents. Import and export of UBL invoices already is a huge step forward. Sending them through Peppol is a next step and can be done in a separate module.
So the first step is to export an UBL invoice which then can be send by a selected method. On the party a selection can be made in which format and how to send the invoice. Based on those choices the right method is chosen.
Might be interresting to see how they work and if tryton could use them as AP. If I have to pay to get my infoices on/from peppol, I might as well support a free software company.
they probably have an API to integrate with Noalyss, which is the reason why they became an access point in the first place
I do care, and I do participate (in several projects, including tryton). However that was not the point here. The point is that from 2026 I’ll have to pay to send invoices, in that case I’d prefer to pay a free software company.
I’ll of course choose what tryton supports
I’ll contact Nymus to get their prices, which do not seem to be publicly available on their website…
I started to implement a module for Nymus but I had to interact with the support because the documentation is not clear about the webhook (like what is the request made; is there any retry mechanism) but after 2-3 email exchanges on the same topic (some answer were off-topic) (and another email to warn them that their text version of the on-boarding email is different from the html version by missing the API key), they decided to stop answering because I did not have yet purchased the contract. Despite my argumentation that I tried to evaluate the solution and that I can not take a contract for a service that is not fully understood.
So I do not think that the Nymus behavior promises a good level of support services.
So I choose instead to implement first a module to support Peppyrus which has even the advantage to be free. But it does not have a webhook so it will have to pull frequently (but the documentation is clear and complete (as far as I know)).
Today I was searching for a Peppol accesspoint which is just an accesspoint and doesn’t scrape my data or gives me an app to make workflows etc. And I found Peppyrus which is a great solution with the simplest API you can think of. Pulling data is not a problem, it can be daily through a Tryton scheduled task which imports the invoice(s). But I’m missing a call to delete an invoice or they do it when they got the acknowledge that the invoice was received correctly.
Hmm, so no end-to-end encryption between the clients (me and my customer or supplier). It’s all about spying and control unfortunately. The problem is not if Peppol will be breached but when. And your whole business lays on the street and you will have a hard time to fight the trouble.
So I hope Peppyrus has implemented some functionality if they must store the data, they will do this offline and encrypted with a key they “lost” by accident.
The peppyrus module has been merged.
The CI is not yet setup because we can not yet register an account for the Foundation.
Any other module implementing Peppol should go to the standard development worklfow.
