Monday, February 16, 2026
10 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where combo products were incorrectly calculating their total price, resulting in double-billing. The fix ensures that remaining combo amounts are accurately divided by the combo quantity, preventing inflated prices for zero-priced items. This ensures accurate pricing for combo orders.
Original PR description
Step to reproduce: - create two products with 0 price, A and B - create combo choice 'combo' with A and B, with max 2 items , free 2 items - create a combo product "test combo" with this combo choice, set price=40 - start pos and select this product - in combo product selector dialog, select same product 2 time and confirm Observation: - the total price is 80 (double then expected) in product screen Cause: - Remaining combo amount is assigned to the last line unit price. - For zero-price items, remaining amount equals combo price. - as `Total = qty × unit price`, as qty =2 it duplicates the combo price. Fix: - Since we assign unit price, divide remaining amount by combo qty. opw-5868831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the shipping weight for deliveries wasn't accurately calculated when products were placed into packages. The fix ensures that the total weight, including packaged items, is correctly computed, improving the accuracy of shipping costs and order fulfillment. This resolves a bug related to how the system handles product weights within packages.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843
Forward-Port-Of: odoo/odoo#245223
Forward-Port-Of: odoo/odoo#238917This pull request fixes a problem where descriptions and product names were not consistently displayed on invoices during printing, particularly when importing factur-x e-invoices. The update ensures that the full invoice description is printed correctly, regardless of the input source, improving invoice accuracy and compliance.
Original PR description
**Issue 1** Steps to reproduce: - Create a new invoice - Add an invoice line, with just a description - Save - On the same line, add any product - Print Issue: Only the custom description will be visible on the line opw-5471809 --- **Issue 2** Steps to reproduce: - Import factur-x e-invoice - Print pdf Issue: Only product name will be printed, even if the invoice record include the complete description opw-5471809 Forward-Port-Of: odoo/odoo#248010
This update fixes an issue where Italian company information (like VAT number and address) wasn't being correctly transferred when creating a company from an ecommerce order. This ensures accurate reporting and compliance for Italian businesses using Odoo, resolving a previous data discrepancy.
Original PR description
**STEP TO REPRODUCE** 1. Create a ecommerce order on a shop page of a italian company. 2. Goes to the checkout page, enter info (company_name, l10n_it_codice_fiscale, l10n_it_pa_index). 3. On the contact created, click on create company. 4. Notice l10n_it fields are not propagated to the company. opw-5477372 Forward-Port-Of: odoo/odoo#248317 Forward-Port-Of: odoo/odoo#246785
This update fixes an issue where the working time assigned to tasks wasn't correctly calculated when switching between companies, particularly when public holidays were involved. Now, the system accurately considers company-specific holidays and the time difference between task assignment and stage changes to determine the correct working time.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883 Forward-Port-Of: odoo/odoo#246994
This update resolves an issue where importing EDI invoices with products restricted to different companies would fail. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors and improving the reliability of invoice processing within multi-company Odoo environments.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912
Forward-Port-Of: odoo/odoo#248623
Forward-Port-Of: odoo/odoo#248149This update resolves an issue where purchase receipts for kits with different unit of measure categories would fail due to a calculation error. The fix ensures accurate quantity calculations for kit products during currency conversions, allowing receipts to post correctly.
Original PR description
Steps to reproduce ------------------ 1. Enable Units of Measure and Automatic Valuation. 2. Create: Product KIT, stockable, UoM category Unit, UoM = Units. BoM for KIT with at least one component…
Steps to reproduce
------------------
1. Enable Units of Measure and Automatic Valuation.
2. Create:
Product KIT, stockable, UoM category Unit, UoM = Units.
BoM for KIT with at least one component whose UoM is in a different
category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.
Issue
-----
Validating the receipt raises:
> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…
If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.
Cause of the issue
------------------
Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108
Fix
---
The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.
https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126
For kits, `qty_received` must be calculated by aggregating component
moves to accurately determine this status. Since the standard logic
crashes due to UoM mismatch, the override in `purchase_mrp` is
necessary to provide the correct quantity for this date selection.
opw-5030761
Forward-Port-Of: odoo/odoo#248318
Forward-Port-Of: odoo/odoo#236276This update fixes an issue where website controllers could be incorrectly linked to irrelevant model types, leading to potential errors. By restricting controller bindings to concrete models, we've enhanced the stability and performance of the Odoo website. This change ensures data integrity and a more reliable user experience.
Original PR description
Before this commit, a website_controller_page could be bound to any sort of model. For some of them this was irrelevant or plain wrong: - transient models: they are not pointing to anything relevant business wise - abstract: they cannot even have records, and most of them are mixin - _auto = False: Those are models with a table which is a custom one. The heuristics here is to say that records are not "real" ones. Also, most of these tables are sqlViews or something similar Business wise there were errors because of this, so this commit introduces a constraint that forbids the above use cases. sentry-6842596566 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246115
This update strengthens the automatic reconciliation of bank statements by ensuring time limits are consistently enforced during imports. Previously, imports could run indefinitely, leading to timeouts. Now, the system automatically limits the import process to the relevant company, preventing long processing times and improving reliability.
Original PR description
The aim of this commit is to prevent a csv import to timeout by applying the `limit_time` parameter for real. We also added the `company_id` parameter to the caller to maximize the chances of…
The aim of this commit is to prevent a csv import to timeout by applying the `limit_time` parameter for real. We also added the `company_id` parameter to the caller to maximize the chances of processing the lines of the statement being imported first. Context: 1) `_cron_try_auto_reconcile_statement_lines` was modified a few times in the last months with the bank reco widget revamping, the perf issues, etc. During that revamp, the timing limitation was made irrelevant if a `batch_size` wasn't provided. While it makes sense that the time limitation is irrelevant without a batch, not raising an error resulted in the client code letting the caller think the time limitation will be applied. Instead, we could provide a default batch_size. 2) The `company_id` parameter wasn't set which combined with no batch_size results in trying to reconcile the entire accounting from every company to which the user has access. Before this commit: - The limit_time parameter is ignored if the `batch_size` parameter isn't provided processing everything in the current transaction. - The company_id parameter wasn't set resulting in trying to reconcile the whole accounting from all accessible companies in the current transaction. After this commit: - We provide a default `batch_size` of 100 and thus we really apply the timing - We provide the `company_id` parameter to limit the reconciliation to the company of the statement. opw-4890008
This update adjusts the calculation of sickness relapse periods for the Belgian payroll module. Starting January 1, 2026, the allowed relapse period between sick leaves will increase from 14 to 56 days, aligning with new Belgian tax regulations. This ensures accurate payroll processing for employees on sick leave.
Original PR description
**Spec :-** Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. **Implementation :-** . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#104769