Odoo Changelog — 2026-05-13

Wednesday, May 13, 2026

7 changes · saas-18.4

Bug Fixes(7)

Resolved issues and error corrections

[FIX] l10n_no_reports: fix VAT declaration XML validation errors

Enterprisesaas-18.4l10n_noMEDIUM

This update resolves issues preventing Odoo's Norwegian VAT XML exports from passing government validation checks. The changes ensure accurate decimal formatting, correct mathematical calculations, and the inclusion of required legal notes, allowing businesses to file their VAT returns correctly and avoid delays. This fix directly addresses compliance requirements with Skatteetaten.

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#116962
Forward-Port-Of: odoo/enterprise#110792

#vat#norway#compliance#tax

[FIX] l10n_be_hr_payroll_sd_worx: skip SDWorx code check for freelancers

PR #117197

Enterprisesaas-18.4l10n_be_hr_payroll_sd_worx

This update resolves an issue where users were receiving an error message when exporting payroll data to SDWorx for freelance employees. The change removes a redundant check for SDWorx codes specifically for freelancers, streamlining the export process. This ensures accurate data transfer for all employee types.

Original PR description

Steps to reproduce:
-------------------------------
1. Install `l10n_be_hr_payroll_sd_worx` module
2. Switch the active company to a Belgian company
3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page.
4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx

Observation:
-------------------------------
A user error is raised stating:
```
There is no SDWorx code defined for the following employees
```

Issue:
-------------------------------
In https://github.com/odoo/enterprise/pull/106065/changes/c19009c776349c3f5d8aebf99aff8efe987b54db The Check for Freelance Employee type was removed, which was earlier added in the fix https://github.com/odoo/enterprise/pull/102211/changes/96724c3cc55725e87e618443b96069921b8f3bda

Solution:
-------------------------------
Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation.

opw-5387342

Forward-Port-Of: odoo/enterprise#114411

#payroll#sdworx#belgium

[FIX] sale_purchase_stock_inter_company_rules: avoid access error

PR #117166

Enterprisesaas-18.4salestock

This update resolves a bug that prevented regular users from accessing sales order details, regardless of whether they were inter-company transactions. Previously, users would encounter access errors when validating sales orders, disrupting the sales process. This fix ensures all sales order information is accessible.

Original PR description

When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not.

This will raise access errors for all regular SO deliveries, regardless of being inter-company or not.

Forward-Port-Of: odoo/enterprise#117047

#sales#orders#access

[FIX] l10n_it_reports: Fix test for partner and bank account import

PR #117001

Enterprisesaas-18.4l10n_it_reports

This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored a previous test data state to ensure the tests continue to run successfully. This ensures accurate reporting functionality for Italian customers.

Original PR description

The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore.

Community PR: odoo/odoo#254505

Task [link](https://www.odoo.com/odoo/project.task/6046189)
task-6046189

Forward-Port-Of: odoo/enterprise#116923
Forward-Port-Of: odoo/enterprise#112794

#reporting#italian#test

[FIX] documents_project: extend template undo with documents folder management

PR #91595

Enterprisesaas-18.4documents_projectMEDIUM

This update resolves a bug where undoing a template conversion left the project's documents folder in an inconsistent state, preventing further template creation. The fix ensures the original documents folder is properly restored and cleaned up during the undo process, improving workflow reliability.

Original PR description

Steps to Reproduce:
---
1. Create a project with documents.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing template conversion should properly restore original project's
documents folder and clean up template's documents folder.

Fix:
---
- Archive original project's documents folder during template creation
- Implement documents folder unarchival during undo operations

task-4916027

#documents#templates#workflow

[FIX] planning_contract: Prevent access error when copy planning slots.

PR #117180

Enterprisesaas-18.4planningplanning_contract

This update resolves an issue where planning managers lacked the ability to copy planning slots to employees with flexible calendars. Previously, access restrictions caused errors. Now, planning managers can successfully copy slots, regardless of the employee's calendar type, improving usability and workflow efficiency.

Original PR description

**Purpose**:
A user with planning manager rights but no access to employee and contract
 records should be able to copy and movea planning slot to an employee with
  a flexible resource_calendar without getting an access rights error.

**Before this commit:**
When copying a planning slot, the system tries to compute the working hours
 over the period of the slot. This will raise an access rights error if the
  user doesn't have access to employee and contract records when the slot is
   moved to a flexible resource_calendar.

**After this commit:**
The user can copy a planning slot without access rights error with only planning manager rights, even if the slot is moved to a flexible resource_calendar.

**Steps to reproduce:**
1.Install Planning and Planning Contract modules.
2.Create a user with only planning manager rights and no access to employee and contract records.
3.Copy a planning slot to an employee with a flexible resource_calendar.

opw-6166557

Forward-Port-Of: odoo/enterprise#115953

#planning#slots#access

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

PR #114798

Enterprisesaas-18.4l10n_pe_ediMEDIUM

This update resolves an issue that caused invoices with combo products lacking taxes to generate errors when sent to Peru's UBL system. The fix ensures that combo product invoice lines without taxes are properly validated, preventing the traceback and allowing invoices to be successfully processed. This improves the reliability of the Peru UBL integration.

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

#pe#ubi#invoice#combo product

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#116962 Forward-Port-Of: odoo/enterprise#110792

Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- In https://github.com/odoo/enterprise/pull/106065/changes/c19009c776349c3f5d8aebf99aff8efe987b54db The Check for Freelance Employee type was removed, which was earlier added in the fix https://github.com/odoo/enterprise/pull/102211/changes/96724c3cc55725e87e618443b96069921b8f3bda Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#114411

When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not. This will raise access errors for all regular SO deliveries, regardless of being inter-company or not. Forward-Port-Of: odoo/enterprise#117047

The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#116923 Forward-Port-Of: odoo/enterprise#112794

Steps to Reproduce: --- 1. Create a project with documents. 2. Convert it into a template. 3. Click on "Undo". 4. Try to convert the project into a template again. Issue: --- After undoing the template conversion, the project's original documents folder remained archived while the template's documents folder stayed active. This inconsistent state prevented subsequent template creation from the same project. Current behaviour: --- A UserError is raised: "You cannot duplicate document(s) in the Trash." Expected behaviour: --- Undoing template conversion should properly restore original project's documents folder and clean up template's documents folder. Fix: --- - Archive original project's documents folder during template creation - Implement documents folder unarchival during undo operations task-4916027

**Purpose**: A user with planning manager rights but no access to employee and contract records should be able to copy and movea planning slot to an employee with a flexible resource_calendar without getting an access rights error. **Before this commit:** When copying a planning slot, the system tries to compute the working hours over the period of the slot. This will raise an access rights error if the user doesn't have access to employee and contract records when the slot is moved to a flexible resource_calendar. **After this commit:** The user can copy a planning slot without access rights error with only planning manager rights, even if the slot is moved to a flexible resource_calendar. **Steps to reproduce:** 1.Install Planning and Planning Contract modules. 2.Create a user with only planning manager rights and no access to employee and contract records. 3.Copy a planning slot to an employee with a flexible resource_calendar. opw-6166557 Forward-Port-Of: odoo/enterprise#115953

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