Odoo Changelog — 2026-05-14

Thursday, May 14, 2026

9 changes · saas-19.1

Bug Fixes(9)

Resolved issues and error corrections

[FIX] l10n_ar: update document types 51-59 per ARCA deprecation of "M" docs

Coresaas-19.1l10n_arMedium

This update corrects a discrepancy in how ARCA-related invoices (document types 51-59) are displayed. The change ensures the documents align with current ARCA regulations by updating naming conventions and PDF headers. This ensures accurate reporting and compliance with Argentinian tax regulations.

Original PR description

**Context:**
* ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59.
* These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations.

**Steps to Reproduce:**
* Install `l10n_ar` module.
* Go to `Accounting -> Configuration -> Document types`.

**Observed behavior:**
* Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification.

**Fix:**
* Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix.
* Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A".
* Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A).
* The existing `res.config.settings` option for injecting the PDF legend remains untouched.

Sources:
  - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp

Ref: https://www.odoo.com/mail/message/1025488740

opw-5953504

Forward-Port-Of: odoo/odoo#254975

#ARCA#Argentina#Accounting#Tax

[FIX] l10n_pe_edi: prevent error when sending the invoice to Peru UBL

PR #117359

Enterprisesaas-19.1l10n_pe_ediMedium

This update resolves an issue that prevented invoices with combo products lacking taxes from being correctly processed when generating Peru UBL invoices. The fix corrects a validation error related to the 'grouping_key' field, ensuring these invoices can now be successfully submitted. This improves the reliability of invoice generation for users in Peru.

Original PR description

A traceback occurs when sending an invoice to Peru UBL if a combo product
invoice line does not have any taxes applied.

Steps to reproduce the error:
- Install ``l10n_pe_edi`` module with demo data
- Switch to PE Company
- Create an invoice > Add a Office Combo product > unset the taxes > Confirm
- Process now

https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552
Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line.
Normally, invoices without taxes are restricted at [1],
but combo products are excluded from this validation at [2].
As a result, combo product lines without taxes bypass the restriction and trigger a traceback.

[1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929

[2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434

sentry-7430552834

Forward-Port-Of: odoo/enterprise#114798

[FIX] l10n_cz_reports_2025: correct values of discount lines in vies report

PR #117324

Enterprisesaas-19.1l10n_cz_reportsMedium

This update fixes an issue where discount lines on invoices were incorrectly calculated in VAT reports. The previous method of using ABS() on negative values resulted in inflated report totals. The fix now correctly handles discount lines by simply flipping the sign of the account balance when it's negative, ensuring accurate reporting.

Original PR description

Step to reproduce:
- install l10n_cz_reports_2025 and switch to cz company
- create a invoice, with cz company ( as partner), of 100.
- when adding products, add "Transaction code" (optional fields) to "Goods"
- Add discount line, set to -10, add "Transaction code" in this line too.
- confirm it

Observation:
- invoice is 90$
- open vies summary report for this year
- value turn out to 110

Cause:
- commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund
- in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong

Fix:
- instead of applying ABS() directly, we flip the signs only for out_* moves,
in short when a account is credited, its balance is < 0 then we flip its sign

opw- 5979262

Forward-Port-Of: odoo/enterprise#117038
Forward-Port-Of: odoo/enterprise#113087

#reporting#VAT#CZ

[FIX] stock: ensure packaging unit and qty are shown for validated transfers.

PR #264218

Coresaas-19.1stockMedium

This update fixes an issue where packaging unit information was hidden on delivery slips after a transfer was validated. Previously, users wouldn't see the packaging unit quantity on the report. Now, the delivery slip accurately reflects the packaging unit and its quantity, even after the transfer is validated, ensuring accurate reporting of stock movements.

Original PR description

Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the…

Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#262722

[FIX] l10n_no_reports: fix VAT declaration XML validation errors

PR #117265

Enterprisesaas-19.1l10n_noMedium

This update corrects errors in the Norwegian VAT XML export that were preventing successful validation by the Skatteetaten (Norwegian tax authority). The changes ensure accurate decimal formatting, mathematical calculations, and required legal notes are included, allowing VAT returns to pass government scrutiny. This resolves a critical issue impacting accurate tax reporting.

Original PR description

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#117168
Forward-Port-Of: odoo/enterprise#110792

[FIX] l10n_in: restrict audit trail deactivation for India

PR #264508

Coresaas-19.1l10n_inMedium

This update ensures Odoo's audit trail feature remains active in India, aligning with Ministry of Corporate Affairs requirements. Previously, the audit trail could be disabled, but this change enforces its continuous maintenance to meet legal obligations. This ensures compliance and reduces potential risks for users in the Indian market.

Original PR description

After the refactor introduced in https://github.com/odoo/odoo/commit/f280f762b6417fa1a0b09649ffbdecafcc7e7579,
The audit trail feature was split into two modes: a lightweight general-purpose mode and a force-restricted mode for specific localizations (e.g., Germany), where deactivation is not allowed once enabled.

In India, as per the requirements of the Ministry of Corporate Affairs, the audit trail must be maintained and cannot be disabled once activated.

This commit extends the force-restricted audit trail mode to the Indian localization (l10n_in) to ensure compliance with statutory requirements.

task-6182002

Forward-Port-Of: odoo/odoo#262508

#compliance#India#audit trail

[FIX] point_of_sale: Prevent assigning multiple POS shop to one cash payment.

PR #264405

Coresaas-19.1point_of_saleMedium

This update fixes a potential issue where users could accidentally assign multiple POS shops to a single cash payment method, leading to errors. Now, the system prevents this, ensuring data integrity and preventing disruptions to the point-of-sale process. This change improves the reliability of payment processing.

Original PR description

**Before this commit**
The user will be able to assign two different POS shop to a cash payment
method by going to
POS -> Configuration -> Payment Methods -> Cash -> Point of sale,
this will not raise a validation error when they try to save it but it
will prevent the user from opening the POS session.

**After this commit**
It will raise a validation error if a user tries to assign more than one POS shop to one cash 
payment method and save it.

opw-6015025

Forward-Port-Of: odoo/odoo#252603

#POS#Payments#Cash

[FIX] account_edi_ubl_cii: only consider taxes from the same fiscal position

PR #264525

Coresaas-19.1account_edi_ubl_ciiaccountMedium

This update fixes an issue where UBL invoices could incorrectly apply taxes due to differences in fiscal positions. The change ensures that only taxes matching the invoice's fiscal position are used during import, leading to more accurate tax calculations and reporting. This improves the reliability of financial data imported from UBL invoices.

Original PR description

When importing a UBL invoice, multiple taxes may share the same rate
(e.g. 21%) but differ by fiscal position. Without filtering, the wrong
tax (e.g. the domestic one for a foreign partner) could be selected.

task-6138749

Forward-Port-Of: odoo/odoo#263872

#UBL#tax#import#invoice

[FIX] account: cash rounding with invoice address

PR #264498

Coresaas-19.1accountMedium

This update resolves a bug that caused invoices with specific customer address configurations to fail during the cash rounding process. The fix ensures the correct partner information is used, preventing errors and allowing invoices to be properly processed. This improves invoice accuracy and reliability.

Original PR description

When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install…

When applying a cash rounding with 'biggest tax' strategy, it happens
that we end up with a MissingError when the invoice's partner is not
defined as commercial_partner_id.

Steps:

- Install membership module
- Create a cash rounding with the 'biggest tax' strategy and 0.05
  rounding
- Enable customer addresses and create a partner P with an invoice
  address I
- Create an invoice, select I as customer (P will be assigned as
  delivery address but this is not relevant)
- Add an invoice line for 100.03 and any tax and apply the cash rounding
- Confirm
-> MissingError: record has been deleted

Cause:

- When creating the cash rounding lines, we set the `partner_id` from the
invoice's partner (in our case partner I, which has P as
`commercial_partner_id`).
- When posting the invoice we look for lines that have partner id
  different than the invoice's commercial partner id and we call the
  write method to set the commercial partner id instead
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239
- In some cases, for example in the `membership` module, the override of
  the write method calls the super() before using `self`.
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49
  But the super triggers the `_sync_tax_lines` mechanism, during which
  the rounding line in deleted
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114
  Therefore `self` doesn't exist anymore
  when comming back in the override

Fix:

Setting the commercial partner on the rounding line to avoid calling the write method

opw-6128868

Forward-Port-Of: odoo/odoo#262759

**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations. **Steps to Reproduce:** * Install `l10n_ar` module. * Go to `Accounting -> Configuration -> Document types`. **Observed behavior:** * Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification. **Fix:** * Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix. * Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A". * Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A). * The existing `res.config.settings` option for injecting the PDF legend remains untouched. Sources: - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp Ref: https://www.odoo.com/mail/message/1025488740 opw-5953504 Forward-Port-Of: odoo/odoo#254975

A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data - Switch to PE Company - Create an invoice > Add a Office Combo product > unset the taxes > Confirm - Process now https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552 Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line. Normally, invoices without taxes are restricted at [1], but combo products are excluded from this validation at [2]. As a result, combo product lines without taxes bypass the restriction and trigger a traceback. [1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929 [2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434 sentry-7430552834 Forward-Port-Of: odoo/enterprise#114798

Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087

Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report. Steps to Reproduce: ========================= 1. Install stock and sale_management modules. 2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings. 3. Create a product with tracking by lot/serial number and configure a packaging unit. 4. Create a SO using this product with a packaging unit and confirm it. 5. Open the related transfer and print the delivery slip before and after validation. Cause of the Issue: ========================= The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure. With This Commit: ========================= This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing) opw-6142052 Forward-Port-Of: odoo/odoo#262722

Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027 Forward-Port-Of: odoo/enterprise#117168 Forward-Port-Of: odoo/enterprise#110792

After the refactor introduced in https://github.com/odoo/odoo/commit/f280f762b6417fa1a0b09649ffbdecafcc7e7579, The audit trail feature was split into two modes: a lightweight general-purpose mode and a force-restricted mode for specific localizations (e.g., Germany), where deactivation is not allowed once enabled. In India, as per the requirements of the Ministry of Corporate Affairs, the audit trail must be maintained and cannot be disabled once activated. This commit extends the force-restricted audit trail mode to the Indian localization (l10n_in) to ensure compliance with statutory requirements. task-6182002 Forward-Port-Of: odoo/odoo#262508

**Before this commit** The user will be able to assign two different POS shop to a cash payment method by going to POS -> Configuration -> Payment Methods -> Cash -> Point of sale, this will not raise a validation error when they try to save it but it will prevent the user from opening the POS session. **After this commit** It will raise a validation error if a user tries to assign more than one POS shop to one cash payment method and save it. opw-6015025 Forward-Port-Of: odoo/odoo#252603

When importing a UBL invoice, multiple taxes may share the same rate (e.g. 21%) but differ by fiscal position. Without filtering, the wrong tax (e.g. the domestic one for a foreign partner) could be selected. task-6138749 Forward-Port-Of: odoo/odoo#263872

When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 Forward-Port-Of: odoo/odoo#262759