Skip to content

[18.0][FIX] account_invoice_en16931: only check the EN16931 config of issuing companies - #47

Open
njeudy wants to merge 1 commit into
akretion:18.0from
Alusage:18.0-fix-en16931-checks-scope
Open

[18.0][FIX] account_invoice_en16931: only check the EN16931 config of issuing companies#47
njeudy wants to merge 1 commit into
akretion:18.0from
Alusage:18.0-fix-en16931-checks-scope

Conversation

@njeudy

@njeudy njeudy commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Fixes #42, reported by @almumu.

_post() runs company_id._en16931_checks() for every sale document, with no condition. In a multi-company database where a single company is subject to the French reform, installing the module makes all the other companies unable to post customer invoices until their own taxes are UNECE-coded — including companies in other countries that will never emit an EN16931 document.

Measured on a clean 19.0 database, whole stack installed, same command before and after: the unconditional check raises The following errors have been detected in company ... that block EN16931 e-invoicing in 390 standard Odoo tests (account 287, sale 45, account_edi_ubl_cii 18, account_payment 8) — all of them tests that create their own company and post an invoice on it. The full run goes from 41 failed, 418 errors of 3902 tests to 39 failed, 51 errors of 3976 tests.

Two occurrences survive, in account.tests.test_audit_trail: those reach the check through the generation path, which this patch deliberately leaves unconditional.

The document itself is never at risk: _en16931_checks() is also called from _en16931_checks_upon_invoice_generation(), so a company with an incomplete configuration still cannot generate an EN16931 document. The call in _post() only anticipates that same error at posting time.

This implements option 2 of the issue rather than option 1 (removing the call), so that nothing is lost for the companies that do issue:

  • res.company.en16931_issuer, unset by default, which localisation modules can set for the companies they cover;
  • the _post() check is gated on it;
  • the configuration stays verifiable at any time from the accounting settings, through a Check Configuration button running the same checks on demand.

Tell us if you'd rather have option 1 — a two-line diff — or a different default for the new field, and we'll adjust.

@ak-git-bot

Copy link
Copy Markdown

Hi @alexis-via,
some modules you are maintaining are being modified, check this out!

…ng companies

_post() runs the company-level configuration check for every sale document,
with no condition. In a multi-company database where a single company is
subject to the French reform, installing the module makes all the other
companies unable to post customer invoices until their own taxes are
UNECE-coded -- including companies in other countries that will never emit an
EN16931 document.

The document itself is not at risk: _en16931_checks() is also called from
_en16931_checks_upon_invoice_generation(), so a company with an incomplete
configuration still cannot generate an EN16931 document. The call in _post()
only anticipates that error at posting time.

Add en16931_issuer on res.company (option 2 of akretion#42), unset by default, that
localisation modules may set for the companies they cover, and gate the _post()
check on it. The configuration remains verifiable at any time from the
accounting settings, through a "Check Configuration" button that runs the same
checks on demand.

Fixes akretion#42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

mod:account_invoice_en16931 Module account_invoice_en16931 series:18.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

account_invoice_en16931: _post() validates the EN16931 configuration of every company, blocking unrelated ones

2 participants