Odoo Changelog — 2026-03-30

Monday, March 30, 2026

5 changes · saas-18.4

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_lu_reports: migrate footnote references to account.report.footnote

Enterprisesaas-18.4l10n_lu_reportsMedium

This update corrects an issue preventing the export of Profit & Loss reports with footnotes enabled in the l10n_lu_reports module. The fix addresses a dependency on an outdated model, ensuring proper XML generation and report functionality. This resolves a technical problem impacting report generation for Luxembourg accounting.

Original PR description

**Steps to reproduce:**
* Install the **l10n_lu_reports** module.
* Go to **Accounting → Reporting → Profit & Loss**.
* Add a footnote on a report line (**⋮ → Annotate**).
* Click **Export (XML)** to open the export wizard.
* Enable **Import notes as references** and export.

**Observed behavior:**
* Export fails with `KeyError: 'account.report.manager'`.
* XML file cannot be generated when references are enabled.

**Cause:**
* The export logic relied on the deprecated `account.report.manager` model.
* This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`.
* The footnote retrieval code was not migrated accordingly.

**Fix:**
* Migrate reference retrieval to use `account.report.footnote`.

opw-5890630

Forward-Port-Of: odoo/enterprise#111845
Forward-Port-Of: odoo/enterprise#107765

#reporting#accounting#lu

[FIX] l10n_it_reports: exclude pens fund tax return

PR #112315

Enterprisesaas-18.4l10n_it_reportsMedium

This update fixes an issue where tax returns for Italian companies incorrectly included pension fund taxes, leading to discrepancies between reports and the backend view. The change excludes these taxes from the tax return calculation, ensuring accurate reporting and alignment with customer data. This resolves a prior inconsistency.

Original PR description

The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend.
Now we exclude them from the tax return domain.

Steps to reproduce:
- Create an Italian company with the Italian CoA
- Install `l10n_it_edi_withholding` (not necessary in v19)
- Create an invoice
- Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT
- Create a tax return

Ticket [link](https://www.odoo.com/odoo/project.task/5909407)
opw-5909407

Forward-Port-Of: odoo/enterprise#111311

#accounting#reporting#Italy#taxes

[FIX] stock_barcode: force lot update if name mismatch

PR #112210

Enterprisesaas-18.4stock_barcodeMedium

This update fixes an issue where scanning a different serial number than the reserved one during batch processing didn't create a new lot. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves data accuracy and reliability.

Original PR description

Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.

Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
    - Enable Lots/Serial Numbers > Create New
- Create a product
    - Barcode 23456789012344
    - Tracked by SN
    - 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details

> The line used the reserved SN

Cause
-----
The existing line gets matched in `_findLine`

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085

because none of the conditions before

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402

get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.

Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).

-----
Ticket:
opw-5216921

Forward-Port-Of: odoo/enterprise#111956
Forward-Port-Of: odoo/enterprise#109671

[FIX] l10n_pe_edi_pos: properly handle consolidation of POS orders

PR #112443

Enterprisesaas-18.4l10n_pe_edi_posMedium

This update fixes an issue where users were incorrectly grouping POS orders in the l10n_pe_edi_pos module. The system now validates order groupings, preventing errors and providing clear messages to users attempting to combine invoices without the necessary shared identifiers. This ensures accurate reporting and compliance for Peruvian businesses.

Original PR description

Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values.

Forward-Port-Of: odoo/enterprise#111616

#Peru#EDI#POS#Accounting

[FIX] l10n_be_reports: include all partner report

PR #112477

Enterprisesaas-18.4l10n_be_reportsMedium

This update resolves an issue where the VAT partner listing report was not displaying all customers. The fix involves adjusting a setting to load all partners, ensuring accurate reporting for VAT compliance in Belgium. This ensures all relevant financial data is available for analysis.

Original PR description

With l10n_be company:
- Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year.
- Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing.
- Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear.
- Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1.

Download the XML again: only the first partner appears (the only that was loaded with the load more limit.

This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72
Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89

Ticket [link](https://www.odoo.com/odoo/project.task/6051120)
opw-6051120

Forward-Port-Of: odoo/enterprise#111783

**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765

The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311

Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting. Steps to reproduce ----- - Enable GS1 nomenclature, lots & batches - Go to Inventory > Configuration > Operation Types > Delivery Orders - Enable Lots/Serial Numbers > Create New - Create a product - Barcode 23456789012344 - Tracked by SN - 1 in stock (SN 1234) - Create a delivery for the product and add it to a batch - Open the batch in barcode - Scan 012345678901234410BATCHSN1 - Confirm the delviery - Go back to the picking and see the lines' details > The line used the reserved SN Cause ----- The existing line gets matched in `_findLine` https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085 because none of the conditions before https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402 get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in. Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence). ----- Ticket: opw-5216921 Forward-Port-Of: odoo/enterprise#111956 Forward-Port-Of: odoo/enterprise#109671

Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616

With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year. - Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing. - Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear. - Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1. Download the XML again: only the first partner appears (the only that was loaded with the load more limit. This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72 Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89 Ticket [link](https://www.odoo.com/odoo/project.task/6051120) opw-6051120 Forward-Port-Of: odoo/enterprise#111783