Tuesday, February 17, 2026
10 changes · saas-18.3
Enhancements to existing features
This update adjusts Odoo's Indian localization to align with new requirements for GST e-invoice processing. Specifically, it switches to a new GST Suvidha Provider (GSP) configuration, ensuring compliance with recent integration updates and proper handling of e-invoices.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243296
This update adjusts the calculations for CP200 seizable amounts in the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new valuation (2026) and updates the relevant percentage parameters to ensure accurate payroll processing according to Belgian tax regulations. This change improves the accuracy of payroll reporting for Belgian employees.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
This update switches the GSP provider used for Indian GST e-invoices to align with recent integration updates. This change ensures Odoo continues to meet regulatory requirements for GST reporting in India, maintaining compliance and accurate reporting.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 Forward-Port-Of: odoo/enterprise#103984
Resolved issues and error corrections
This update resolves an issue where the 'Contact Us' button on product pages wasn't correctly redirecting users to snippets created through drag-and-drop. The fix ensures that anchors in the button URL are properly handled, allowing for seamless redirection to the intended snippets, particularly when dealing with zero-priced products.
Original PR description
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work…
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor. for ex: `#snippet-anchor` in the `Button URL` field in the settings. Cause: -------- This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place. Solution: ------------ To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on. This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside. Steps to reproduce: ----------------------- 1. Create a db in version 18.3 with website_sale installed. 2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings. 3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button. 4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings. 5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet. Ref PR: ---------- https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399 Attachments: ----------------- **Before Fix:** [vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0) **After Fix**: [vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5) - OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test report for MRP was failing because the administrator user lacked the necessary permissions to select product variants. This update adds the required user rights, allowing the test to pass and ensuring accurate reporting of product variants within the system. This resolves a critical issue impacting test report accuracy.
Original PR description
The _/mrp:TestReportBom.test_mrp_report_bom_variant_selection_ test was failling because administrator user couldn't use the product variants. The needed dropdown menu to switch variant wasn't displayed and the test failed. We add the "product.group_product_variant" rights to the user. Runbot error: 238917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an infinite page reload cycle when applying multiple gift cards from the same program. The fix addresses a discrepancy in how discount lines are handled, specifically related to multi-gift card applications. This ensures a smoother checkout experience for customers using gift cards.
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 update fixes an issue where the system incorrectly treated re-deliveries as returns, leading to a single shipping label being generated. Now, when returning multiple packages, the system accurately processes all incoming shipments as returns, ensuring correct label generation and tracking.
Original PR description
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery -…
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery - Multiple packages - Validate transfer - Return - Validate IN - Return again - Add the UPS under the "additional info" tab - Ensure still multiple packages - Validate OUT Cause ----- When preparing the shipping data, we go through https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121 which leads us to do https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155 so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`. https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58 From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns. ----- Ticket: opw-5866100 Forward-Port-Of: odoo/odoo#246946
This update corrects a bug preventing loyalty rewards from applying correctly when products are purchased in non-unit quantities (e.g., dozens). The fix ensures that rewards are accurately calculated based on the actual quantity purchased, regardless of the unit of measure. This improves the accuracy of loyalty program discounts.
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 a reporting issue where VAT numbers were incorrectly excluded from INF reports for Estonian businesses. Now, the reports include partners without VAT numbers, and a clearer warning is displayed when VAT information is missing, ensuring more accurate financial reporting. This improves compliance and data reliability.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update resolves an issue where Fedex freight delivery requests were failing due to missing information required by the Fedex API. The fix adds a necessary field, 'expressFreightDetail', to the API request, allowing delivery rates to be retrieved and validated. This ensures users can accurately process 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