| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Discuss (mail)
• Invoicing (account) |
| Community Apps Dependencies | Show |
| Lines of code | 4044 |
| Technical Name |
eh_l10n_fr_einvoicing |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
France e-Invoicing
Build Factur-X, route through a PDP or Chorus Pro, and keep a sealed audit trail for the French reform.
Why this module
France e-Invoicing
Factur-X you can actually send
A working CII builder emits UN/CEFACT Cross Industry Invoice XML across all four Factur-X profiles, gated by the per profile Business Term set, and a pikepdf pass embeds it into a PDF/A-3 with conformance metadata and dangerous features stripped. EN 16931 pre flight blocks a malformed document before it ever reaches a platform.
Generic REST today, named connectors as profiles
The shipped Generic REST adapter submits to any DGFiP conformant PDP and a direct Chorus Pro adapter handles public sector. Named platform connectors are preconfigured endpoint and path profiles on the same framework, not separately certified live links, so you always know what is wired and what needs partner credentials.
Sealed trail, not just a status field
Every send is appended to a SHA-256 hash chain anchored to the company SIRET, locked against deletion at both the ORM and the Postgres layer, and scanned daily for tampering. The lifecycle log is append only, payloads are hashed at approval to catch tampering before send, and credentials live in an encrypted vault.
Day in the life
From posted invoice to sealed archive
An accountant posts a French customer invoice. The module maps it to CII, runs the EN 16931 pre flight, and builds a Factur-X draft on the invoice form with a clear status chip. The accountant clicks send; the Generic REST adapter submits to the configured PDP, captures the platform reference, advances the lifecycle to submitted, and seals the document into the hash chained archive. As the platform reports progress, a webhook or the status poll cron advances the state through validated, deposited, delivered, and validated, each transition checked by the state machine and written to the append only log. A supplier e-invoice arriving inbound is parsed and turned into a draft vendor bill, de duplicated so a re-run never creates a second copy. At month end the e-reporting builder assembles the B2C, cross border, and reverse charge batch, and the nightly cron confirms the archive chain is still intact.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
State transitions run through a compare and set SQL update that flips the row only while it still holds the expected state, so two cron workers or a webhook racing a poll can never double advance the same request.
The lifecycle defines exactly which next states each state allows. Any transition outside that map, including a direct edit of the State field in the form, is refused with a clear message rather than silently corrupting the trail.
Each PDP callback is checked by URL token, then HMAC-SHA256 over the body, then by event id. A replay of an already processed event id returns an idempotent response without repeating the state change.
The canonical XML is hashed at approval and re-checked at send time, so any change between approval and submission is caught as a TOCTOU defense before the document leaves the server.
Outbound calls pin the platform leaf certificate at the TLS 1.3 handshake. A fingerprint mismatch aborts the handshake before any request body or Authorization header is transmitted, then surfaces as a clean operator facing error.
Inbound supplier invoices are de duplicated on platform and external reference, so re-running the fetch cron never creates a second draft vendor bill for the same document.
Archive rows cannot be deleted at the ORM layer and are also protected by a Postgres rule that turns a DELETE into a no-op, reinstalled on every upgrade so it self heals if a DBA drops it.
Stored audit payloads recursively redact any key that looks like an api key, secret, token, password, or authorization header, including inside nested arrays, so credentials never survive into the log.
Once a live invoice has been submitted in production, the platform record cannot be downgraded back to a test tier, mirroring the production seal expected by tax authorities.
What is inside
Built to do the job, end to end.
- Factur-X and CII builder. Builds a UN/CEFACT Cross Industry Invoice D16B from the posted move per EN 16931 Business Term mapping, with all four Factur-X profiles (Minimum, Basic WL, Basic, EN 16931) gated by the per profile BT set. A pikepdf pass embeds the XML into a PDF/A-3, stamps conformance XMP, and strips JavaScript, OpenAction, Launch, and similar features. An optional Ghostscript post pass is available for stricter conformance.
- EN 16931 pre flight validator. Runs the move data against a curated subset of the EN 16931 and FNFE-MPE business rules, including header, party, totals, coherence, and VAT breakdown checks, returning fatal and warning findings. It is not a full schematron run; it catches the fatal classes that would cause a platform to reject the document, and a full schematron pass can be wired in later.
- Guarded lifecycle state machine. An 18 state model, the 14 DGFiP business states plus four rejection and terminal branches, driven by an explicit allowed transition map. A compare and set SQL update prevents concurrent advance, illegal transitions are refused, and every move is written to an append only lifecycle log.
- PDP and Chorus Pro adapters. A configurable Generic REST adapter submits, polls status, fetches inbound, cancels, and submits e-reports against any DGFiP conformant platform. A direct Chorus Pro adapter implements the Piste OAuth2 exchange and submission endpoints for B2G. Named platform connectors ship as preconfigured endpoint and path profiles on the same framework.
- PPF directory lookup. Resolves a recipient SIRET to its chosen platform through the PPF directory, with SIRET validation and a six hour TTL cache stored per company so repeat lookups stay offline fast. The response signature check is a placeholder pending the published DGFiP public key.
- E-reporting builder. Assembles a canonical JSON e-reporting payload for B2C, cross border, and reverse charge transactions, with a monthly batch shape, per currency summarisation, and a correction filing reference that supersedes a prior batch.
- Hash chained archive. Seals each outbound document into an append only SHA-256 hash chain anchored to the company SIRET, locked against deletion at the ORM and Postgres layers, with a daily integrity cron that flags any broken link on the company record.
- Security envelope. AES-256-GCM credential vault keyed outside the database, pinned TLS 1.3 transport with per platform certificate fingerprints, HMAC-SHA256 signed webhooks with token and idempotency, per company record rules, and defused XML parsing for inbound documents.
Honest about the edges
What this does not do, so nothing surprises you.
- This module does not replace a PDP or the Chorus Pro portal. You still need an account and credentials with a DGFiP accredited platform, or Piste credentials for Chorus Pro, before any document can leave Odoo.
- The shipped live transport is the configurable Generic REST adapter plus the direct Chorus Pro adapter. Named platform connectors ship as preconfigured endpoint and path profiles on top of the generic adapter and need their final partner credentials and any provider specific auth confirmed before production use.
- Document output is Factur-X PDF/A-3 and standalone UN/CEFACT CII XML. A UBL 2.1 syntax serializer is not generated by this version even though a UBL format flag is selectable.
- The EN 16931 pre flight covers a curated subset of the business rules, not the full DGFiP schematron. It catches the fatal classes that block submission; a complete schematron run can be added separately.
- PPF directory response signature verification is a placeholder that trusts a signed flag and logs otherwise, pending the DGFiP published public key. It is not yet a full JOSE signature check.
- The PDF/A-3 pass is a baseline conformance build. Some platforms that demand embedded ICC profiles or fully embedded fonts may require the optional Ghostscript post pass enabled by the operator.
- Mandate timing and penalty amounts are set by the French authorities and can change; confirm current obligations and dates with your platform or advisor.
- Inbound supplier documents are turned into draft vendor bills for review; an operator still adds lines and posts them.
France e-invoicing Odoo, Factur-X Odoo 19, EN 16931 Odoo, UN CEFACT CII invoice, PDP Odoo connector, Plateforme de Dematerialisation Partenaire, Chorus Pro Odoo, PPF directory lookup, DGFiP e-invoicing reform, e-reporting B2C cross border, FNFE-MPE Factur-X profiles, PDF/A-3 invoice, French electronic invoicing, facturation electronique, Odoo Community localization France
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module