Friday, April 3, 2026
7 changes · 19.0
Enhancements to existing features
This update adds new configuration options for DHL Express shipments, allowing users to control pickup scheduling, utilize customer-provided reference numbers, and automatically upload Odoo invoices for export shipments. These changes enhance shipping accuracy and streamline the process of matching shipping documents with accounting records.
Original PR description
Add three new configurable options to the DHL Express REST integration: 1. Request Pickup (new Boolean field, default True for backward compat): Controls the pickup.isRequested flag in shipment…
Add three new configurable options to the DHL Express REST integration: 1. Request Pickup (new Boolean field, default True for backward compat): Controls the pickup.isRequested flag in shipment requests. When disabled, DHL will not schedule a pickup — useful when managing pickups externally or dropping off at a DHL location. Previously hardcoded to True. 2. Enhanced References (new Boolean field): When enabled, uses the Customer Reference from the SO (client_order_ref) as the shipment reference (customerReferences with typeCode CU) instead of the SO number. Useful when customers provide their own PO/reference numbers that should appear on the shipping label. 3. Upload Odoo Invoice (new Boolean field): When enabled and the shipment is an export (commercial invoice required), uploads the Odoo-generated invoice PDF inline in the shipment request as a DHL Paperless Trade document (documentImages with typeCode INV, base64 encoded). Requires a posted invoice on the SO before shipping. This ensures export documents match the actual accounting records. All features are opt-in via carrier configuration fields in the Options section, preserving full backward compatibility.
Resolved issues and error corrections
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
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…
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-5438723This 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
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-6026748This 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…
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
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