Odoo Changelog — 2026-04-03

Friday, April 3, 2026

9 changes · 19.0

Bug Fixes(9)

Resolved issues and error corrections

[FIX] l10n_co_dian: fix commercial event XML generation

Enterprise19.0l10n_co_dianMEDIUM

This update corrects errors in the generation of XML files for commercial events in the Co-DIAN integration. Previously, incorrect naming conventions and data extraction led to validation failures. Now, commercial events are generated using the same XML format as invoices, ensuring accurate data transmission to the Dian authorities.

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 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

#co-dian#commercial events#xml#integration

[FIX] databases: hide edit properties when not applicable

PR #108056

Enterprise19.0databases

This update resolves an issue where the 'Edit Properties' button was unexpectedly appearing in the project view. The fix ensures this button only appears when relevant, streamlining the user experience for managing project database settings. This prevents confusion and improves usability.

Original PR description

Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit…

Steps to produce:
---
- Install `Databases` modules.
- Go to project > Switch to list view and open project.
- Click on the gear icon > Click `Edit Properties.`

Observation:
---
- Clicking `Edit Properties` does nothing.

Root cause:
---
- The `Edit Properties` action appears whenever a properties field is present in the view.
- Currently, in `project.project` the field `database_kpi_properties` is added from database module (See [1]).
- Here at [2], the field is added in `edit_project` view.
- However, the field is only visible when `database_hosting` is set, and its value is different from `other`.

Solution:
---
- Patched `FormController.getStaticActionMenuItems()` and added a condition to make the `addPropertyFieldValue` menu item unavailable when the current model is `project.project`.

[1]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/models/project_project.py#L36
[2]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/views/databases_project_views.xml#L158

Note:
---
- Also found that, clicking `Edit Properties` from a page other than the KPI page does nothing.
 We could either show a guiding `dialog box` or limit the visibility of `Edit Properties` to the KPI page only.

opw-5933007
---

#project#database#UI

[FIX] l10_ae_hr_payroll: [hr_employee]prevent traceback on Annual Leave Days calculation for new employees

PR #112867

Enterprise19.0hr_payroll

This update resolves a technical issue that caused Odoo to crash when calculating annual leave days for newly created employee records. The fix adds a check to prevent errors during calculations, ensuring the 'Annual Leave Days Total' field functions correctly for all employees, including those just added to the system.

Original PR description

This commit will add a guard condition to the `l10n_ae_annual_leave_days_total`'s compute method to skip SQL execution when the record has no database ID.

Why:
Users experienced a server-side traceback when opening Odoo Studio on the employee form and enabling the 'Annual Leave Days Total' field. The traceback occurred because the field's compute method attempted to execute a direct SQL query using `self.ids`.

What:
- Added a check for `self.ids` at the beginning of the compute method.
- Ensured the field defaults to `0` or a neutral value if the record is still in the "New" state.

task-5940225

#payroll#employee#annual leave

[FIX] sale_purchase_inter_company_rules: get missing variant in inter company purchase

PR #107122

Enterprise19.0sale_purchase_inter_company_rulesMEDIUM

This update resolves an issue where manufacturing orders weren't correctly incorporating components from intercompany purchase orders with 'never variant' products. The fix ensures that component data is accurately retrieved from the purchase order, enabling proper manufacturing order creation. This improves the reliability of intercompany transactions.

Original PR description

In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.

Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
    -  Never variant with at least two values
    -  MTO and manufacture
* Create a bom,
    - Company : company B
    - Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant

Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.

opw-5438723

#intercompany#purchase#manufacturing#variants

[FIX] l10n_ch_hr_payroll_elm_transmision: Fix lpp applied when not insured

PR #112829

Enterprise19.0hr_payrolll10n_chMEDIUM

This update resolves an issue where the LPP (Labor Pension Plan) was incorrectly applied to employee salaries in the Swiss payroll module when employees were not covered by insurance. The fix ensures that LPP contributions are only applied to insured employees, aligning with Swiss tax regulations and improving payroll accuracy.

Original PR description

Forward-Port-Of: odoo/enterprise#112824

#payroll#switzerland#lpp#tax

[FIX] account_accountant: correctly parse amounts in in regex extract

PR #110410

Enterprise19.0accountantMEDIUM

This update fixes an issue where amounts with thousand separators (like 1,334.00) were incorrectly parsed, leading to potential errors in reconciliation reports. The change introduces a new function to intelligently split amounts, ensuring accurate conversion to decimal values and improving the reliability of financial reporting.

Original PR description

When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to…

When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
  
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
    
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
    
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
    
Examples:
    
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
    
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.

Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)

task-6026748

#finance#reconciliation#accounting

[FIX] mrp_mps: take into account safety inventory for indirect demand

PR #112982

Enterprise19.0mrpMEDIUM

This update corrects an issue where the Master Production Schedule (MPS) wasn't accurately accounting for safety stock levels when calculating indirect demand. The change ensures that demand forecasts are adjusted to include safety stock, leading to more reliable production planning and reduced stockouts. This improves inventory management efficiency.

Original PR description

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112811
Forward-Port-Of: odoo/enterprise#107671

#mps#inventory#safety stock

[FIX] l10n_us_direct_deposit: update Wise sandbox URLs before end date

PR #112921

Enterprise19.0l10n_us_direct_deposit

This change updates URLs used for testing Wise direct deposit integrations to reflect Wise's upcoming domain change from sandbox.transferwise.tech to wise-sandbox.com. This ensures continued functionality of test and sandbox payment flows, though a new sandbox account will be needed.

Original PR description

Wise is deprecating their legacy sandbox (sandbox.transferwise.tech) in June 2026. Replace all sandbox URLs with the new wise-sandbox.com domain to avoid breaking test/sandbox payment flows.

- API: api.sandbox.transferwise.tech → api.wise-sandbox.com
- Portal: sandbox.transferwise.tech → wise-sandbox.com

Note: API keys from the legacy sandbox are not transferable to the new environment. Affected users will need to create a new sandbox account, though the impact should be minimal as most customers do not actively use the sandbox.

task-6074132

#wise#sandbox#direct deposit#testing

[FIX] industry_fsm_sale: prevent double discount on task sales order

PR #112942

Enterprise19.0industry_fsm_saleMEDIUM

This update corrects a bug where discounts were applied twice to service tasks, resulting in incorrect pricing. The fix ensures discounts are applied correctly based on the sales order settings, preventing over-discounting and ensuring accurate pricing for service tasks.

Original PR description

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable…

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112761
Forward-Port-Of: odoo/enterprise#103950

#discount#pricing#task#sales order

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

Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit Properties` does nothing. Root cause: --- - The `Edit Properties` action appears whenever a properties field is present in the view. - Currently, in `project.project` the field `database_kpi_properties` is added from database module (See [1]). - Here at [2], the field is added in `edit_project` view. - However, the field is only visible when `database_hosting` is set, and its value is different from `other`. Solution: --- - Patched `FormController.getStaticActionMenuItems()` and added a condition to make the `addPropertyFieldValue` menu item unavailable when the current model is `project.project`. [1]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/models/project_project.py#L36 [2]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/views/databases_project_views.xml#L158 Note: --- - Also found that, clicking `Edit Properties` from a page other than the KPI page does nothing. We could either show a guiding `dialog box` or limit the visibility of `Edit Properties` to the KPI page only. opw-5933007 ---

This commit will add a guard condition to the `l10n_ae_annual_leave_days_total`'s compute method to skip SQL execution when the record has no database ID. Why: Users experienced a server-side traceback when opening Odoo Studio on the employee form and enabling the 'Annual Leave Days Total' field. The traceback occurred because the field's compute method attempted to execute a direct SQL query using `self.ids`. What: - Added a check for `self.ids` at the beginning of the compute method. - Ensured the field defaults to `0` or a neutral value if the record is still in the "New" state. task-5940225

In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost. Steps to reproduce: ------------------- * Enable intercompany transaction * Enable variant grid entry * Enable multistep routes * Unarchive MTO * Settings>Users & Companies>Companies * Enable Generate Sales Orders in company A * Create a product: - Never variant with at least two values - MTO and manufacture * Create a bom, - Company : company B - Add a component with apply on variant: choose one of the variants * Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B * Confirm the sales order in company B -> The manufacture order does not include the components that are applied on variant Observation: ------------- When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order. That function will create the sale order from the data of the purchase order: https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64 When preparing the value for each order line, the attribute value for the never variant will not be retrieved: https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64 Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO. opw-5438723

When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models. Added a new function `split_amount_str`in utils which will give integer and decimal part for different number formats. This is a heuristic approach, meaning it aims to provide the best possible result for valid inputs. Invalid or ambiguous formats are not guaranteed to be parsed correctly and may result in ('0', '0'). For the two capturing groups case, the first group is treated as the integer part and the second as the decimal part, allowing users to Explicitly split amounts like 9065 into 90.65 by using two groups in their regex. Examples: EU format: 1.334,15 → 1334.15 US format: 1,334.15 → 1334.15 Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups) Additional tests were added to ensure amounts with thousand separators are correctly parsed. Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748) task-6026748

Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838 Forward-Port-Of: odoo/enterprise#112811 Forward-Port-Of: odoo/enterprise#107671

Wise is deprecating their legacy sandbox (sandbox.transferwise.tech) in June 2026. Replace all sandbox URLs with the new wise-sandbox.com domain to avoid breaking test/sandbox payment flows. - API: api.sandbox.transferwise.tech → api.wise-sandbox.com - Portal: sandbox.transferwise.tech → wise-sandbox.com Note: API keys from the legacy sandbox are not transferable to the new environment. Affected users will need to create a new sandbox account, though the impact should be minimal as most customers do not actively use the sandbox. task-6074132

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings. * Create a pricelist with a price rule of type discount that applies 10 percent discount to every product. * Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist. * Go to Field Service > Create a Task, and set `Customer` to Acme Corporation. * Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order <h2>Observed behavior:</h2> The discount is applied twice to the product on SO: **Product**: Service on Timesheets **Unit Price**: `$40` (excluding tax) **First discount:** The 10 percent discount on the unit price of the product. Product unit price is set from `$40 -> $36 ` **Second discount:** The 10 percent discount on the SO line itself. `$36 -> $32.4 ` The untaxed amount is: `$32.40` which should be `$36.00` <h2>Root cause:</h2> This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice. <h2>Solution:</h2> When creating the sales order: * **Discount setting is on:** use list price so the discount is applied from the sales order. * **Discount setting is off:** set the product unit price to the discounted price. [1]- https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 [2]- https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788 opw-5432088 Forward-Port-Of: odoo/enterprise#112761 Forward-Port-Of: odoo/enterprise#103950