[16.0] Migrate account_invoice_en16931 and the einvoicing stack to 16.0

[njeudy]

WIP — migration of the whole fr-einvoicing stack to 16.0, rebased on upstream/16.0.

Ports the modules to 16.0: Python API gaps (env._, read_group, button_draft, hard_lock_date, reversal_move_id…), views (<setting>→o_setting_box, attrs=, <tree>), and the tax layer rewritten on the 16.0 tax engine.

Modules — all ten are installable: True

• account_invoice_en16931 — EN16931 Factur-X core
• l10n_fr_account_invoice_en16931 — FR EN16931 layer
• l10n_fr_einvoicing
• l10n_fr_einvoicing_import
• l10n_fr_einvoicing_purchase
• l10n_fr_einvoicing_sale
• l10n_fr_einvoicing_dashboard_banner
• l10n_fr_einvoicing_directory_import
• l10n_fr_einvoicing_batch_payment (renamed from l10n_fr_einvoicing_payment_batch_oca: account_payment_batch_oca is 18.0-only, replaced by account_payment_order)
• account_invoice_en16931_py3o

Dependencies: plain OCA 16.0 is enough

Two prerequisites were missing from OCA 16.0 when this port started and were carried on Alusage forks. Both have since landed upstream, so no fork is needed: the VATEX codes are on OCA/community-data-files 16.0, and is_france_country / _get_siren() / _get_siret() / _get_nic() are on OCA/l10n-france 16.0 since 9e662b1a (27/07). Reported by @almumu, verified here.

That same commit extended _check_siret to the vat field — a French VAT number must now end with the nine digits of the SIREN. The demo of l10n_fr_einvoicing carries an inconsistent pair (siren 892350455 / vat FR23334175221, which belongs to SIREN 334175221), so loading it aborts the database. Fixed here as FR78892350455; the same pair is still on 18.0.

Rebase on upstream/16.0

The branch is rebased on the seven commits carried onto 16.0. Four of them had been backported here beforehand and were dropped in favour of upstream's own, along with the local fix for #36 — upstream's [FIX] don't store fr_einvoicing_required removes the mass recompute at the root.

Two of those commits are written against 18.0 APIs and needed re-porting: the twelve self.env._() calls they add (before 17.0 the helper returns the string and silently drops its arguments), and BT-23, which now decides on product_id.type == "consu" — on 16.0 the stock module adds ('product', 'Storable Product') to product.type, so every physical-goods invoice would go out as a mixed process (M1/M2) instead of B1/B2.

Two fixes carried temporarily

#46 (#43, Discount precision) and #47 (#42, EN16931 config scope) are applied here so they can be tested on 16.0, and are proposed upstream on 18.0 where they belong. They will be dropped from this branch once merged there, or adjusted if a different shape is preferred.

Test run

Clean 16.0 community database, demo data, cascade install, plain OCA l10n-france 16.0 — so with _check_siret actually in place. All ten modules install, l10n_fr_einvoicing passes its 17 tests, and the demo loads. Full run: 31 failed, 9 errors of 1603 tests, all outside this stack (base, mail, sms, google_gmail, digest, base_vat, account_invoice_import).

Context and rationale: #28

[njeudy]

Pushed the fix for #36 on this branch as well — the MemoryError was found while migrating, and the code is identical across 16.0 / 18.0 / 19.0. Standalone PR against 18.0: #37.

[almumu]

@njeudy First of all, thank you for this work!

We deployed this branch (f2a298a) on a 16.0 community database to validate it, and it holds up:
the nine modules in scope install with no error against our own addons path, and the suite passes 0 failed, 0 error(s) of 49 tests. Thanks for the MIGRATION-16.0.md — it made the review mucheasier.

Everything below is either a correction that removes work from your instructions, or a defect that pre-exists on 18.0 and that this port merely surfaced. None of it is caused by the backport.

One correction to MIGRATION-16.0.md, which also explains a difference between our two runs

The document says the l10n_fr_siret helpers (_get_siren(), _get_siret(), is_france_country) exist on the 18.0 branch only, and backports them on Alusage/l10n-france. But all three are on OCA/l10n-france 16.0 — is_france_country at res_partner.py:159, _get_siren at :197, _get_siret at :228. They landed on 27/07 with 9e662b1a ("[IMP] l10n_fr_siret: add get methods for siren/siret/nic"); the previous commit touching that file dates from May 2024. So the backport is not needed any more — plain OCA 16.0 is enough, one less fork to provision.

But that same commit did not only add the three helpers: it also added a constraint.

# l10n_fr_siret/models/res_partner.py:42 (OCA l10n-france 16.0, added by 9e662b1a)
    @api.constrains("siren", "nic", "vat")
    def _check_siret(self):

Among other things it now requires a French VAT number to end with the 9 digits of the SIREN. Before 9e662b1a the constraint did not watch the vat field at all.

That is where our two runs diverge, and why installing this branch with demo data aborts the database for us and not for you: your instance consumes a reduced copy of l10n_fr_siret carrying the helpers without the constraint, while we consume the whole OCA 16.0 branch, so we get both.
l10n_fr_einvoicing's demo creates Burger Queen with siren = 892350455 and vat = FR23334175221 — that VAT belongs to SIREN 334175221, so the pair is inconsistent and the constraint rejects it during the demo load. The consistent value for that SIREN would be FR78892350455.

The same pair is on the 18.0 branch, so it is not a backport artefact; it will surface there too as soon as an instance runs a l10n_fr_siret newer than 27/07 with demo data.

Second correction, unrelated

The VATEX codes are also already on OCA/community-data-files 16.0, so that backport is not needed either.

Three things that block installing the stack on a multi-company database

We then installed it on a real multi-company database (one French company subject to the reform, alongside companies in two other countries (Italy and Spain). Three defects block that, none caused by the backport and all three present on 18.0 as well:

• account_invoice_en16931: _post() validates the EN16931 configuration of every company, blocking unrelated ones #42 — the company configuration check is not scoped, so posting customer invoices stops working in companies that will never emit an EN16931 document.
• account_invoice_en16931: the Discount decimal precision check blocks posting without affecting the output #43 — the Discount decimal precision check blocks posting over a value that never reaches the document, and decimal.precision is database-global.
• account_invoice_en16931: the schematron validation is silently skipped when no Saxon server is reachable #44 — the fr-ctc schematron is silently skipped when no Saxon server is reachable, so documents are emitted as if they had been validated.

And one that is already reported by someone else: l10n_fr_einvoicing_sale._action_confirm() calls ensure_one() before its own loop, which breaks confirming sale orders in batch or on an empty recordset, for every company — and the module is auto_install: True. #41 fixes it on 18.0; it would be worth carrying into this branch.

We have the 16.0 environment set up and will keep it, so if any of this is useful to test — a change on this branch, a fix on 18.0 you want checked against 16.0, or a case you cannot reproduce — we are happy to run it and report back. Thanks again for opening the branch up; it is what made it possible for us to evaluate the reform stack on 16.0 at all.

[njeudy]

thanks for your tests, will check this and update this PR (and resolv conflicts too) :)

[njeudy]

Thanks for running it on a real 16.0 database — the branch is updated, and all four points are addressed.

The two backports are gone. You're right on both, and I checked before removing them: is_france_country, _get_siren(), _get_siret() and _get_nic() are on OCA/l10n-france 16.0 since 9e662b1a (27/07), and unece_tax_vatex.xml plus unece_vatex_id are on OCA/community-data-files 16.0. MIGRATION-16.0.md no longer instructs anyone to provision those forks — two repositories fewer.

The demo VAT number is fixed, and your diagnosis of the divergence was exactly right. FR23334175221 is the VAT number of SIREN 334175221, while the partner carries SIREN 892350455 — the consistent value is FR78892350455 (key = (12 + 3 × (siren mod 97)) mod 97 = 78). Worth noting for @alexis-via that the same pair is still on 18.0, so any 18.0 instance running a post-27/07 l10n_fr_siret with demo data will hit it too.

#41 is already on the 16.0 branch upstream, so the rebase brought it in.

#42 and #43: both patched on this branch, and proposed upstream on 18.0 where they belong — #47 and #46. They are kept here so you can test them on 16.0 straight away, and will be dropped from this branch once merged upstream (or adjusted, if Alexis prefers a different shape). On #42 I went with your option 2 rather than option 1, plus an on-demand Check Configuration button so issuing companies keep an early warning.

On that one, running the suite turned up an argument stronger than the multi-company case. On a clean 19.0 database with the whole stack installed, the unconditional _post() check raises ... that block EN16931 e-invoicing in 390 standard Odoo tests (account 287, sale 45, account_edi_ubl_cii 18, account_payment 8) — every test that creates its own company and posts an invoice on it. The full run goes from 41 failed, 418 errors of 3902 tests down to 39 failed, 51 errors of 3976 tests with the patch. Same code on 18.0, so the effect should be identical there. Details in #47.

#44: commented on the issue with what we measured on our own deployment, including a Saxon configuration that fixes the codedb lookups without --insecure, and the image we run.

The branch is also rebased on upstream 16.0, which had grown seven commits meanwhile — four of them were backports carried here and are now dropped in favour of upstream's own. Two of those commits needed re-porting: twelve self.env._() calls (which silently drop their arguments before 17.0) and BT-23, which now decides on product_id.type == "consu" — on 16.0 a storable product is "product", so every physical-goods invoice would have gone out as a mixed process (M1/M2) instead of B1/B2.

We ran the cascade install ourselves this time, on a clean 16.0 database with demo data and plain OCA l10n-france 16.0 — so with the _check_siret constraint actually in place. All eight modules install, l10n_fr_einvoicing passes its 17 tests, the demo loads, and Burger Queen lands with FR78892350455. The remaining failures are all outside the stack: base, mail, sms, google_gmail, digest, base_vat, and account_invoice_import.