Odoo Changelog — 2026-04-06

Monday, April 6, 2026

3 changes · saas-19.2

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_co_dian: fix commercial event XML generation

Enterprisesaas-19.2l10n_co_dianMedium

This update corrects errors in the generation of XML files for commercial events, ensuring accurate data transmission to the Dian authority. The fix resolves issues with incorrect naming conventions and UUID extraction, preventing rejection of submitted documents. This ensures compliance and proper processing of commercial events.

Original PR description

When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went…

When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls
_add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g.  "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash:

Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE.

_dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's.

We now render commercial events like how invoices are rendered.

[1] odoo/enterprise#107170

opw-6065701

Forward-Port-Of: odoo/enterprise#112973
Forward-Port-Of: odoo/enterprise#112812

#accounting#tax#compliance

[FIX] timesheet_grid: revamp installation wizard

PR #113098

Enterprisesaas-19.2timesheet_gridMedium

This update streamlines the installation process for the ActivityWatch timesheet module, providing clearer instructions and improved verification steps. Additionally, the timesheet assistant has been enhanced with better rule data, clearer field labels, and more informative event display, resulting in a more user-friendly experience.

Original PR description

This PR revamps the ActivityWatch installation wizard to adapt the instructions to the new installers, as well as providing more ways to check that the server is successfully installed and running.

It also provides a few other fixes related to the assistant in general.

Task-6042434

Forward-Port-Of: odoo/enterprise#112127

#timesheet#installation#assistant#activitywatch

[FIX] stock: show correct quantities on delivery slip

PR #257552

Coresaas-19.2stockMedium

This update fixes an issue where delivery slips incorrectly displayed the quantity of packaged items. The change ensures that the correct quantity (5) is shown when printing delivery slips with items packaged in 'packs of 6', resolving a discrepancy between ordered and delivered amounts.

Original PR description

Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity.

## Steps to replicate:
- Install Purchase and Inventory with demo data
- Settings > Enable 'Units of Measure & Packagings' and 'Packages'
- Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor.
- Create new RFQ with the same vendor for 'Desk pad' having quantity 10
- Confirm RFQ > Go to receipt > Details
- Create and Set Destination Package to 
    - LOT A 5 pack of 6 
    - LOT B 5 pack of 6
- Validate Delivery Order and Print the Delivery Slip

## Observed Behavior:
Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect.

The correct quantity ordered and delivered should be 5 (Pack of 6).

## Root cause:
This unintentional behavior occurs after commit [1].

When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging.

As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed.

Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5.
[2]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945 
[3]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88
## Solution:
Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly.

**Before:**
<img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" />
**After:**
<img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" />

[1]:
https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28 

opw-5930343

Forward-Port-Of: odoo/odoo#256849
Forward-Port-Of: odoo/odoo#249779

When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls _add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g. "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash: Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE. _dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's. We now render commercial events like how invoices are rendered. [1] odoo/enterprise#107170 opw-6065701 Forward-Port-Of: odoo/enterprise#112973 Forward-Port-Of: odoo/enterprise#112812

This PR revamps the ActivityWatch installation wizard to adapt the instructions to the new installers, as well as providing more ways to check that the server is successfully installed and running. It also provides a few other fixes related to the assistant in general. Task-6042434 Forward-Port-Of: odoo/enterprise#112127

Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity. ## Steps to replicate: - Install Purchase and Inventory with demo data - Settings > Enable 'Units of Measure & Packagings' and 'Packages' - Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor. - Create new RFQ with the same vendor for 'Desk pad' having quantity 10 - Confirm RFQ > Go to receipt > Details - Create and Set Destination Package to - LOT A 5 pack of 6 - LOT B 5 pack of 6 - Validate Delivery Order and Print the Delivery Slip ## Observed Behavior: Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect. The correct quantity ordered and delivered should be 5 (Pack of 6). ## Root cause: This unintentional behavior occurs after commit [1]. When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging. As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed. Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5. [2]- https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945 [3]- https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88 ## Solution: Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly. **Before:** <img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" /> **After:** <img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" /> [1]: https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28 opw-5930343 Forward-Port-Of: odoo/odoo#256849 Forward-Port-Of: odoo/odoo#249779