Odoo Changelog — 2026-04-23

Thursday, April 23, 2026

3 changes · saas-18.2

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_co_dian: correct sts namespace for DIAN Credit Note

Enterprisesaas-18.2l10n_co_dian

This update fixes an issue where the namespace for DIAN credit notes was incorrectly configured, causing errors when submitting to the DIAN tax authority. The namespace has been standardized to ensure proper compliance with DIAN requirements. This resolves a recurring problem identified in a previous related issue.

Original PR description

Issue:
Incorrect `sts` namespace raises several issues when sent to dian

Steps to reproduce:
- On a Colombian company
- Create a credit note
- Send to DIAN

Current Behavior:
- Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`
while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures`

Expected Behavior:
- Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`.

It was forgotten that Credit Note were part of the Invoices in the last refactor.

As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test.

opw-6077050

Forward-Port-Of: odoo/enterprise#113643

#accounting#compliance#colombia

[FIX] helpdesk_sale: remove tracking on SO's status

PR #114668

Enterprisesaas-18.2helpdesk_sale

This update removes automatic tracking of Sales Order status changes within Helpdesk Tickets' chatter. Previously, status updates would log messages, which has now been corrected by explicitly disabling tracking on linked Sales Orders. This improves the clarity and accuracy of chatter conversations.

Original PR description

Before this commit:

- The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status.

After this commit:

- Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`.
- Status updates to linked SOs will no longer automatically post tracking messages in chatter.

task-6079809

Forward-Port-Of: odoo/enterprise#114078

#helpdesk#sales order#chatter

[FIX] project_timesheet_forecast : Check for no-calendar leaves and adjust tz

PR #114474

Enterprisesaas-18.2project_timesheet_forecastMEDIUM

This update corrects a reporting error that incorrectly showed planned hours on public holiday days. The fix ensures the system accurately excludes public holidays from time sheet forecasts by considering timezone differences and handling general holiday calendars correctly. This improves the accuracy of time tracking reports.

Original PR description

### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to…

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#111846

#reporting#timesheet#public holidays

Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#113643

Before this commit: - The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/enterprise#114078

### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to 11:59PM with a calendar - Create a planning slot for a resource that overlap with the public holiday - Check the Timesheets / Planning analysis report - Group by employees > day **- Check the date of the public holiday and notice there are still planned hours shown** - Remove the calendar from the public holidays that we created previously - Check the report once again **- Notice the day of the public holiday and the day after has no planned hours** ### Cause: In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule. Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies ### Fix: We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves. opw-5027070 Forward-Port-Of: odoo/enterprise#111846