Configuration

• Go to menu Invoicing > Configuration > Settings > Invoicing, under Electronic Invoices.
• Formulate a domain for which invoices the dialect should become PEPPOL. By default it is [], so all UBL invoices will be PEPPOL. If you want this only for Belgian partners, then you can fill here for example: [(‘partner_id.country_id.code’, ‘=’, ‘BE’)] Or you can choose to enable this only for selected partner ids.
• You can configure a default tax to use in case an invoice line has no tax specified. This is necessary for example in case of an NGO to satisfy business rule BR-CO-18. Any tax you choose must also have a UNECE tax type (eg. VAT) and tax category (eg. “Services outside scope of tax”) defined.
• You can configure a default unit of measure, of which the UNECE code will be used in case an invoice line has no unit or product unit. A typical default unit could be the Odoo ‘unit’, configured with a UNECE code of UN, XUN or C62. This is to satisfy rule BR-23.
• Go to menu Contacts Fill the field coc_registration_number for your own company’s partner record and for those partners that you want to send e-invoices to.
• Go to menu Contacts > Configuration > Localization > Countries On any country relevant for invoice traffic, configure the correct PEPPOL EAS id. For the Netherlands, this is for example 0106, which stands for Dutch chamber of commerce number.
• Either: make sure that every invoice has a bank account filled in; Or: make sure that your payment modes have a fixed connection to a bank account. To do the latter: Go to menu Invoicing > Configuration > Management > Payment mode Per payment model, set the field bank_account_link to fixed

Usage

In the invoice form click on button Send & Print.

If the invoice matches the configured domain for PEPPOL, the invoice will be generated and validated according to the stricter PEPPOL 3.0 BIS standard.

The validator on https://test.peppolautoriteit.nl/validate can be used to test the validity of the generated XML file. There are other online validators around as well.

Known issues / Roadmap

• Currently, the user needs to configure the PEPPOL EAS id for each country. For the Netherlands, this is for example 0106, which stands for Dutch chamber of commerce number. During review, it was noted that (defaults for) these codes could be mapped automatically upon installation of the module, using a post-init hook or a noupdate=1 XML file. This could still be done, saving the perhaps not so tech- or PEPPOL-savvy user some configuration.

• Currently, this module defines allowed EAS codes from a CSV file. But, other modules could also benefit from this data. So the data could be moved to a separate module in the community-data-files repository.

• When adding a delivery partner to an invoice, some PEPPOL warnings arise about DeliveryParty that should not be included. This is non blocking but it is nice if we could also add a clause in the module to remove this.

• A unit test should be added that actually verifies against PEPPOL and not only against general UBL. This could consist of:

  • Choose a default tax and UoM for this module in res.config.settings
  • Create an outgoing invoice on the main company to some partner
  • On the main company’s partner record, choose any EU country, set a VAT number and a CoC number
  • On the partner record that is being invoiced, do the same.
  • On the res.country records that are being used by these partners, configure a valid PEPPOL EAS code.
  • On both involved partners, configure a bank account.
  • The payment mode that is selected on the invoice should have a fixed link to a bank journal.
  • On this bank journal, select a bank account of type IBAN.
  • Create a tax and selecting a UNECE tax category (eg. VAT) and a tax type (eg. S)
  • The invoice lines should have this tax defined.
  • Validate the invoice, generate the XML, and pass it through the validator.

• This needs to be tested more thoroughly on credit/refund invoices, and purchase invoices.

• Currently, the module fill in the due date under PaymentTerms, but we could prefer the Odoo payment terms field if it is filled.

• Upon clicking Print and Send button on invoice, when an error is encountered, the popup will coincide with the mail.compose popup. Improve the UI experience to the user here.

Bug Tracker

Bugs are tracked on GitHub Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us to smash it by providing a detailed and welcomed feedback.

Do not contact contributors directly about support or help with technical issues.

Credits

Maintainers

This module is maintained by the OCA.

OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.

This module is part of the OCA/edi project on GitHub.

You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.