Tuesday, February 17, 2026
10 changes · saas-18.4
Resolved issues and error corrections
This fixes a problem where Italian electronic invoice imports could fail in multi-company setups when an invoice line referenced a product limited to another company. Businesses using multiple Italian companies can now import these invoices more reliably without company mismatch errors.
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#248720
Forward-Port-Of: odoo/odoo#248149Accounting report searches can now apply a journal filter to more than one journal at a time. This makes it easier for users to review combined activity across selected journals without running separate reports or relying on a filter that only used the first journal.
Original PR description
In accounting reports, we want to be able to filter on multiples journals if needed. This filter will allow us to do this. Using `context['search_default_journal_id'] = journal_ids` doesn't work as only the first id is passed to the filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247731
This fix ensures customers cannot claim eWallet points after their expiration date. It protects businesses from unintended discounts or credits being applied past their valid period and keeps loyalty balances aligned with program rules.
Original PR description
### Issue: Due to this issue, ewallet points are claimable after expiry. #### Steps to reproduce: 1- Create a ewallet program, and generate an ewallet for a partner. 2- Set the expiration date in the past. 3- Create a SO with the same partner. 4- Click on reward. Expected: The ewallet shouldn't be claimable. Current outcome: The ewallet is claimable. opw-5476686 Forward-Port-Of: odoo/odoo#248528 Forward-Port-Of: odoo/odoo#247740
Customers can now use multiple gift cards from the same program during checkout without the page repeatedly refreshing. This improves checkout reliability and prevents affected orders from getting stuck at the delivery step.
Original PR description
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add…
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add a deliverable product to cart. 3- Open cart and add both gift card codes. 4- Click on checkout to navigate to delivery step. The page is going to keep refreshing. ### Cause: The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.: https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24 After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line. However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card ### Fix: This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines. Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card). opw-5485912 Forward-Port-Of: odoo/odoo#248215
This fix ensures delivery orders keep the correct shipping weight after products are placed into packages. It prevents packages from incorrectly showing zero weight, helping avoid inaccurate carrier rates, labels, and delivery handling information.
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#238917Attendance managers and officers can now correctly edit attendance records when they have the right responsibility. This prevents unexpected access behavior and improves confidence that attendance corrections are handled by the appropriate people.
Original PR description
The commit https://github.com/odoo/odoo/commit/d115cca1296c0bd20a2875bdaadf2a9136c33dda introduced the opportunity for attendance managers to edit their subordinates attendances, but the condition was lacking parenthesis, leading to an unexpected behaviour. This commit changes the condition so that it is possible both for a manager and an officer to do the edition. It also rewrite the tests in order to be more thorough. No related task Forward-Port-Of: odoo/odoo#248580 Forward-Port-Of: odoo/odoo#248471
Loyalty rewards now correctly calculate qualifying quantities when products are sold in alternative units of measure, such as dozens instead of individual units. This ensures customers receive the expected free products or discounts and prevents missed rewards on valid sales orders.
Original PR description
### Issue: Due to this issue, applying a different uom than unit one, will not apply the reward regarding to quantities. #### Steps to reproduce: 1- Create a program: buy 12 get 6 free. 2- Create a SO, add a dozen of product to SOL. 3- Click on reward. Expect: 6 free unit is added. Current outcome: Nothing is added. Unless you add 12 dozens which is going to add 6 units. ### Cause: In checking rules, `product_uom_qty` is directly used without conversion to quantity. Note: `test_different_uom_to_hours_on_sale_order_confirmation` is failing due to this fix, because the uom_id unit/dozens and hours/days are not compatible. As this is not possible in UI, IMO we can delete the breaking SOL in that test. opw-5913638 Forward-Port-Of: odoo/odoo#248527 Forward-Port-Of: odoo/odoo#247743
This update fixes an issue where duplicate DateV identifiers could be assigned to partners, even after archiving. The change ensures that a unique DateV ID is always required, regardless of a partner's active status, preventing data inconsistencies. This improves data accuracy for German reporting.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update resolves a technical error that was causing a crash when creating new payroll records. The fix utilizes a standard Odoo method to handle virtual records, ensuring the payroll module functions correctly and reliably. This prevents disruptions to business processes.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303
This update resolves an issue where Odoo couldn't successfully process Fedex delivery requests due to a missing piece of information required by the Fedex API. Specifically, the system was failing with an 'INVALID' error. By adding a necessary field to the API request, we now ensure accurate delivery rate calculations and validation for Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590