Wednesday, March 4, 2026
5 changes · saas-18.4
Enhancements to existing features
This update simplifies the process for Italian businesses filing withholding tax returns. The system now defaults to a monthly reporting period, aligning with Italian regulations and addressing previous difficulty in configuring this setting. This change improves compliance and reduces administrative burden.
Original PR description
In Italy, withholding tax return periodicity is monthly. but it's hard to discover/configure. Default periodicity should be monthly. task-5985704 Forward-Port-Of: odoo/enterprise#109185
This update ensures Odoo complies with recent changes mandated by the Uruguayan tax authority (DGI) regarding Electronic Sales Records (CFE). Specifically, it adds a new option for documenting exports handled by third parties and updates how reference invoices are transmitted to the DGI, improving legal compliance.
Original PR description
Purpose: The DGI introduced changes in CFE version 25. The following changes below needs to be implemented for legal compliance.
Required Changes:
- Introduce a new selection value,("91", "Export under Mandate")for field, l10n_uy_edi_cfe_sale_mode. This option is required when documenting export operation performed as a mandating entity, where the definitive export will be carried out by a third party.
- The reference document(credit note or debit note) of an existing account move will need to send:
- Amount (MntCFEref)
- Currency (TpoMonedaRef)
- Exchange Rate (TpoCambioRef) if the currency is not Uruguayan Pesos
task-5419331
task-5419331
Forward-Port-Of: odoo/enterprise#108430
Forward-Port-Of: odoo/enterprise#103881Resolved issues and error corrections
This update fixes an issue where employees with flexible calendars were incorrectly displaying unavailable days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the usability of the planning app for flexible workers.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#109281
Forward-Port-Of: odoo/enterprise#105521This update resolves an issue where foreign vendor VAT invoices were not correctly identifying the country of origin for JPK reports. The team has implemented a fix to ensure the country code is accurately included in vendor bills, aligning with Polish tax regulations and improving reporting accuracy. This change was prompted by previous work to address invoice-going-out country codes.
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
This update corrects inaccuracies in the XML files used for processing Swedish payments (SEPA). Specifically, it ensures the correct BIC number is used, removes a misleading placeholder value, and allows users to select the appropriate payment version even without using the SEPA payment method. This improves the accuracy and reliability of Swedish payment processing.
Original PR description
We currently have customizations for the iso20022 xml file for payments in Sweden. But those customizations aren't correct. This commit fix multiples issues: 1) In DbtrAgt, we sometimes have bankgiro information. But this node should always contain the BIC number for Swedish payments. 2) The _get_cleaned_bic_code method was replacing the real bic code with a fake value like 'SE:Bankgiro', but this seems to be wrong. None of the SE banks ask for this BIC, so we remove it. 3) The sepa_pain_version field is supposed to tell Odoo which pain version to use. But the problem is this field is computed, and only editable once the user set the SEPA payment method, but for iso_se, we want to let the user choose as well, even if he didn't add SEPA as payment method. This commit change the invisible on the field, so it can be edited as soon as iso_se is in the journal payment methods. task-5427570 Forward-Port-Of: odoo/enterprise#105536