Daily updates from Odoo
Tuesday, February 10, 2026
12 changes · 17.0
Resolved issues and error corrections
This update fixes a bug in the loyalty discount calculation within the Point of Sale system. Previously, discounts were applied in the wrong order, leading to inaccurate discount amounts. The change ensures that discounts are applied correctly, guaranteeing accurate loyalty program rewards.
Original PR description
**Steps to produce:** - Install `point of sale` without demo data. - From the settings, enable `Promotions, Coupons, Gift Card & Loyalty Program`. - Create a product test with a sale price of `1000`.…
**Steps to produce:**
- Install `point of sale` without demo data.
- From the settings, enable `Promotions, Coupons, Gift Card & Loyalty Program`.
- Create a product test with a sale price of `1000`. (Remove the taxes).
- Create `3 loyalty programs`:
- `100 off` on a specific product test.
- `10% off` on a specific product test.
- `20% off` on a specific product test.
- Now go to the POS and add the test product in order.
**Issue:**
- As the product price is `1000`, the first discount applies a `fixed amount of
100`. The remaining amount is `900`, on which a `10% discount` applies (`-90`). The final `20% discount` should then apply to `810`, resulting in a discount of `-162`. However, the system currently applies `-160 instead`.
**Root cause:**
- At [1], in the `_getDiscountableOnSpecific` method, when the system attempts to apply the `final 20% discount`, it first evaluates the previously configured discounts. During this evaluation, `percentage discounts` are applied `before fixed amount discounts`. As a result, the `10% discount` is applied on the `original price (1000 → 900)`, followed by the `fixed 100 discount (900 → 800)`. The `final 20% discount` is then calculated on `800`, leading to an incorrect discount of `160 instead of 162`.
**Solution:**
- In the solution, we don’t just apply the raw percentage discount. We compare the computed percentage reduction against the `actual discount amount`, cap it to the smaller value, and then subtract safely so the remaining amount never overshoots.
[1]https://github.com/odoo/odoo/blob/50308d7d69af6848c2aa2cca8e5dbfff1491c983/addons/pos_loyalty/static/src/overrides/models/loyalty.js#L1249-L1262
**Before:**
<img width="500" height="336" alt="image" src="https://github.com/user-attachments/assets/2fa6e76e-ff02-4cda-b5e5-63ec1d099cba" />
**After:**
<img width="500" height="284" alt="image" src="https://github.com/user-attachments/assets/e3fe0adf-e64a-45bc-a8a1-939427af9e9e" />
opw-5407559
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue preventing correct receipt validation for purchase orders of kits with different unit of measure categories. The fix accurately calculates quantities for kit receipts, ensuring proper accounting and inventory valuation when currency exchange rates are used.
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-5030761This update resolves an issue where typing outside the "Enter Code" popup in Point of Sale (POS) would incorrectly increase product quantities. The fix prevents global key events from affecting orderlines when the popup is active, ensuring accurate quantity updates. This improves the overall POS user experience.
Original PR description
When the "Enter Code" text popup is open in POS, typing outside the input field still affected the active orderline quantity because the number buffer globally captured key events. This change blocks…
When the "Enter Code" text popup is open in POS, typing outside the input field still affected the active orderline quantity because the number buffer globally captured key events. This change blocks number buffer handling only when the top popup is the text input popup. Steps to reproduce: ------------------- * Open a POS session. * Add a product (quantity one). * Click “Enter Code”. * Click outside the popup input, then type a code. > Observation: Quantities on the selected product increase even though a popup modal is open. Why the fix: ------------ The number_buffer was listening to global keyup events and only ignored events targeting INPUT/TEXTAREA. With a modal open, keystrokes outside inputs still modified quantities. We now: Ignore number buffer events only when the top popup is TextInputPopup (so virtual numpad popups still work). Make popup usage optional (inject via env.services?.popup) to avoid breaking cases that don’t start the popup service. opw-5144792
This update fixes an issue where the order web preview incorrectly showed the tax description instead of the tax name. The change ensures that the correct tax name is displayed in the preview, improving accuracy and clarity for sales teams. This aligns with upcoming Odoo versions.
Original PR description
Currently, the `Tax name` configured on taxes is not applied in the web preview of orders. **Steps to reproduce:** - Install the `sale_management` module. - Go to Invoicing > Configuration >…
Currently, the `Tax name` configured on taxes is not applied in the web preview of orders. **Steps to reproduce:** - Install the `sale_management` module. - Go to Invoicing > Configuration > Accounting > Taxes. - Create a new tax, `Tax Type: Sale`and set `Description`. - Create a new quotation and apply this tax to a product. - Click Preview > observe the `Taxes` value. **Observation:** - Web preview incorrectly displays `description` instead of `tax name`. **Root Cause:** At [1], the sale portal web preview template uses `description or name`, which causes an incorrect tax description to be displayed in the preview. **Fix:** This commit ensures that `Tax Name` is used when rendering taxes in the portal preview for Reantal, Sales, and Subscriptions apps. This aligns with the behavior in the next versions. Related Enterprise PR: https://github.com/odoo/enterprise/pull/106830 [1]: https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/views/sale_portal_templates.xml#L598 opw-5411496
This update resolves an issue where account numbers weren't being properly logged during the processing of UBL (Universal Business Language) invoices. By logging the account numbers directly, the system now accurately tracks financial data related to these invoices, improving reporting and reconciliation. This ensures data integrity for financial transactions.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247693
This update resolves a performance issue in our Point of Sale system by optimizing how pricelists are loaded. Previously, the system generated many unnecessary database queries, leading to slow loading times. This change significantly reduces query volume, resulting in a faster and more responsive POS experience, especially when dealing with large product catalogs.
Original PR description
Currently when a pricelist is set on a POS session, N+1 queries are generated when loading the data. These come from the search in _get_applicable_rules() in _compute_price_rule() which is often run on one record at a time by its wrappers. This commit avoids the extra queries by performing the filtering through Python, which allows the ORM to effectively cache previously fetched pricelist rules. Benchmark opening /pos-self/data | product.product count | Before | After | Queries Before | Queries After | | --------------------- | ------ | ----- | ------------- | ------------- | | 1,500 | 2.16s | 0.70s | 1,711 | 184 | | 15,000 | 24.91s | 6.45s | 17,175 | 396 | opw-5477715
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The change ensures that the employee's work email field is properly cleared during the contract signing process, preventing this duplication. This improves data accuracy and consistency for employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797
This update fixes an issue where draft journal entries in the payroll accounting module were incorrectly using the end of the month instead of the payslip pay period date. This ensures accurate accounting records and proper financial reporting for employee payroll.
Original PR description
Steps to Reproduce: - install payroll accounting module - create or update existing employee contract - change schedule pay to semi-monthly - create a payslip and validate it. - create draft entry and open the journal entry Issue: - The accounting date of the draft entry is the last date of the month. - It should be the end date of payslip pay period. Reason: - While creating draft entry it takes the last date of the month instead of the end date of the payslip Solution: - assign end date of payslip pay period instead of last date of the month task-5419465
This update addresses an issue where rounding units were unexpectedly appearing in financial reports and views. By adding a new name to the rounding units, the changes prevent their display, resulting in cleaner and more accurate reporting. This enhances the overall clarity and professionalism of our financial data presentation.
Original PR description
adhoc-ticket-side: 82382
This update fixes a display issue in the order web preview where tax names weren't correctly shown. Previously, the preview showed the tax description instead. The fix ensures that the configured tax name is displayed, providing accurate tax information in the portal preview for sales orders.
Original PR description
Currently, the `Tax name` configured on taxes is not applied in the web preview of orders. **Steps to reproduce:** - Install the `industry_fsm_sale` module. - Go to Invoicing > Configuration >…
Currently, the `Tax name` configured on taxes is not applied in the web preview of orders. **Steps to reproduce:** - Install the `industry_fsm_sale` module. - Go to Invoicing > Configuration > Accounting > Taxes. - Create a new tax, `Tax Type: Sale`and set `Description`. - Open Field Service, create a new task, and set a Customer and Sales Order Item (using a sale order with the newly created tax). - Click the gear icon > Share > Copy to copy the portal link. - Open the link in a new window and observe the Taxes value. **Observation:** - Web portal preview incorrectly displays `description` instead of `tax name`. **Root Cause:** At [1], the project portal web preview template uses `description or name`, which causes an incorrect tax description to be displayed in the preview. **Fix:** This commit ensures that `Tax Name` is used when rendering taxes in the portal preview. Related community PR: https://github.com/odoo/odoo/pull/241850 [1]: https://github.com/odoo/enterprise/blob/6d5e02b61f90ec490fdad72d87ea73d1c6adcfac/industry_fsm_sale/views/project_portal_templates.xml#L77-L79 opw-5411496
This update resolves a reporting issue where the tax amount for EU imports was incorrectly duplicated in the Spanish VAT reports (mod 390). The fix corrects a misconfiguration in the tax template, ensuring accurate reporting of import duties for Spanish companies using the l10n_es module.
Original PR description
How to reproduce: - Install the l10n_es module - Swithc to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for O% EU G, there is two tags for the mod 390, the one for grid 26 being wrong opw-5867849
This update incorporates new statistical trade codes (2026) required for accurate reporting based on European Union regulations. These codes, sourced from the National Bank of Belgium, ensure Odoo Enterprise complies with international trade statistics reporting standards. This change improves the accuracy of financial data for businesses involved in cross-border transactions.
Original PR description
This commit adds 2026 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes opw-5504187