Friday, April 3, 2026
6 changes · saas-18.4
Resolved issues and error corrections
A bug in the Colombian edition of Odoo (l10n_co_edi) was causing invoice creation to crash. This was due to a duplicate entry in a selection field, leading to an error. This fix ensures stable invoice creation for Colombian users.
Original PR description
The `l10n_co_edi_operation_type` field on `account.move` had two entries with the same selection value `'23'`:
('23', 'Nota Crédito para facturación electrónica V1 (Decreto 2242)'), ('23', 'Inactivo: Nota Crédito para facturación electrónica V1 (Decreto 2242)'),
This caused an OWL crash when opening the invoice form:
"Got duplicate key in t-foreach: 23"
__Steps to reproduce:__
1- Install the l10n_co_edi module
2- switch to colombian company
3- Activate the developer mode
4- Go to Credit Note > Create
__NOTE__: The javascript error is only visible on version 18.4 but the duplicate selection is present since 17.0.
opw-5969595This update ensures Odoo correctly calculates and reports Ecuadorian withholding taxes based on the latest regulations (Resolución N.º NAC-DGERCGC26-00000009). The changes involve updating unit tests to reflect the new withholding percentage requirements, ensuring accurate tax reporting for Ecuadorian businesses.
Original PR description
In accordance with the implementation of the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. Unit tests are updated to be based on the new withholding percentages. BP #110343 Forward-Port-Of: odoo/enterprise#112715 Forward-Port-Of: odoo/enterprise#110712
This update fixes an issue where the LPP (a Swiss tax levy) was incorrectly applied to employee payrolls when employees were not covered by insurance. The change ensures that LPP is only calculated for employees with the necessary insurance coverage, aligning with Swiss tax regulations. This correction improves payroll accuracy and reduces the risk of incorrect tax payments.
Original PR description
Forward-Port-Of: odoo/enterprise#112824
This update corrects a calculation error in the Master Production Schedule (MPS) that was misinterpreting safety stock levels. It now accurately accounts for safety inventory when forecasting demand for dependent components, ensuring more reliable production planning and reducing potential stockouts. This improves the accuracy of the MPS and optimizes inventory levels.
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 sales order settings, preventing over-discounting and ensuring accurate order totals. This impacts how discounts are calculated for field 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
This update fixes an issue where incorrect DTE (Digital Tax Document) XML files received by the system were automatically creating purchase invoices. The fix ensures that invalid DTEs with the wrong document type are discarded, preventing incorrect invoice generation and maintaining data accuracy. This improves the reliability of the purchase order process.
Original PR description
A supplier DTE xml should be discard when being fetched by a DTE incoming server if it has the wrong document type, meaning no account move should be created from it. Steps: - Have purchase journal using documents - Setup an incoming mail server, with DTE option enable, with email address X - Send an email to X with a supplier DTE xml of type 52 (TipoDTE element) - Fetch mails from the incoming server -> a bill has been generated and filled, it shouldn't Cause: The check on document type has been removed with the refactor 42744fcecdbd36ea0101070c68299227a9f204a6 Fix: Reintroduce the check in `_process_incoming_supplier_document` before creating any record opw-5978959