Odoo Changelog — 2026-09-10

Thursday, September 10, 2026

2 changes · master

Refactoring(2)

Code cleanup and technical improvements

[REF] account: move inventory valuation account

Enterprisemasteraccount_accountantaccount_reportsl10n_be_reportsl10n_cl_edimrp_accountantpos_pricerpurchase_accountantsale_account_accountantsale_stock_rentingMedium

This update reorganizes where inventory valuation and accrual account settings are managed, making accounting configuration more consistent across purchasing, sales, stock, manufacturing, and point of sale flows. It also improves performance for some Chilean electronic invoicing valuation calculations by avoiding repeated account lookups.

#accounting#inventory valuation#accruals#settings#performance

[REF] l10n_es*: unify invoice type and VAT regime code handling

PR #267440

Coremasterl10n_esl10n_es_edi_facturael10n_es_edi_siil10n_es_edi_tbail10n_es_edi_verifactul10n_eu_ossMedium

Spanish electronic invoicing now uses one shared invoice type and VAT regime setup across SII, TicketBAI, Veri*Factu and related POS flows. This makes values visible and correctable before posting, then preserves them after posting so reported invoices do not change unexpectedly if tax settings are later updated.

Original PR description

Before this, SII, TicketBAI and Veri*Factu each re-derived a move's
"TipoFactura" (F1/F2/R1-R5) and "ClaveRegimenEspecialOTrascendencia" at
send time, from `l10n_es_is_simplified` (a boolean guessed from
partner/amount) and ad hoc, slightly different tax-based rules per EDI.
Credit notes needed a manual reason anyway, so each EDI kept its own
private field for it (`l10n_es_sii_refund_reason`,
`l10n_es_tbai_refund_reason`, `l10n_es_edi_verifactu_refund_reason` +
`l10n_es_edi_verifactu_clave_regimen`). None of this was visible or
correctable from the invoice before sending, and an already-declared
move's values could silently drift if its tax configuration changed
afterwards, since they were never actually stored.

Both values now live directly on `account.move` as real fields:
`l10n_es_invoice_type` (replacing `l10n_es_is_simplified`, since a
boolean can't express F2 vs R5 vs a refund reason) and
`l10n_es_regime_code`/`l10n_es_regime_code_additional`. They're
computed once from the move's taxes and the company's special V
regime, editable before posting to correct the odd case the com
gets wrong, and frozen once posted so a declared invoice keeps
what was sent regardless of later changes elsewhere.

`account.tax` gets a matching `l10n_es_regime_code`, filled fro
tax's own chart-template data instead of re-derived from its ty
amount at report time. `l10n_es_applicability` (the tax's AEAT
Impuesto: VAT/IPSI/IGIC) moves from `l10n_es_edi_verifactu` to
alongside it, since it's a property of the tax itself, not of one EDI's
document format, and `l10n_es`'s own regime-code catalog already keyed
off it. This also fixes a silent gap: `l10n_eu_oss`'s EU_FIELD_
already stamped this field on the OSS taxes it generates, but t
only existed when Veri*Factu happened to be installed, so OSS t
a plain Spanish company silently lost their applicability.

SII/TicketBAI/Veri*Factu no longer maintain their own refund-re
field or re-derivation logic: they read `l10n_es_invoice_type`/
`l10n_es_regime_code` straight off the move, and only extend th
catalog (`_l10n_es_regime_code_labels`/`_l10n_es_regime_available_codes`
on `account.tax`/`res.company`) with the codes their own format
each gated behind its own boolean so the EDI's can be installed
together in any order without one silently exposing another's c
The same `l10n_es_invoice_type` field is reused on `pos.order`
TicketBAI/Veri*Factu POS integrations, replacing their own sepa
refund-reason fields there too.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this, SII, TicketBAI and Veri*Factu each re-derived a move's "TipoFactura" (F1/F2/R1-R5) and "ClaveRegimenEspecialOTrascendencia" at send time, from `l10n_es_is_simplified` (a boolean guessed from partner/amount) and ad hoc, slightly different tax-based rules per EDI. Credit notes needed a manual reason anyway, so each EDI kept its own private field for it (`l10n_es_sii_refund_reason`, `l10n_es_tbai_refund_reason`, `l10n_es_edi_verifactu_refund_reason` + `l10n_es_edi_verifactu_clave_regimen`). None of this was visible or correctable from the invoice before sending, and an already-declared move's values could silently drift if its tax configuration changed afterwards, since they were never actually stored. Both values now live directly on `account.move` as real fields: `l10n_es_invoice_type` (replacing `l10n_es_is_simplified`, since a boolean can't express F2 vs R5 vs a refund reason) and `l10n_es_regime_code`/`l10n_es_regime_code_additional`. They're computed once from the move's taxes and the company's special V regime, editable before posting to correct the odd case the com gets wrong, and frozen once posted so a declared invoice keeps what was sent regardless of later changes elsewhere. `account.tax` gets a matching `l10n_es_regime_code`, filled fro tax's own chart-template data instead of re-derived from its ty amount at report time. `l10n_es_applicability` (the tax's AEAT Impuesto: VAT/IPSI/IGIC) moves from `l10n_es_edi_verifactu` to alongside it, since it's a property of the tax itself, not of one EDI's document format, and `l10n_es`'s own regime-code catalog already keyed off it. This also fixes a silent gap: `l10n_eu_oss`'s EU_FIELD_ already stamped this field on the OSS taxes it generates, but t only existed when Veri*Factu happened to be installed, so OSS t a plain Spanish company silently lost their applicability. SII/TicketBAI/Veri*Factu no longer maintain their own refund-re field or re-derivation logic: they read `l10n_es_invoice_type`/ `l10n_es_regime_code` straight off the move, and only extend th catalog (`_l10n_es_regime_code_labels`/`_l10n_es_regime_available_codes` on `account.tax`/`res.company`) with the codes their own format each gated behind its own boolean so the EDI's can be installed together in any order without one silently exposing another's c The same `l10n_es_invoice_type` field is reused on `pos.order` TicketBAI/Veri*Factu POS integrations, replacing their own sepa refund-reason fields there too. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr