**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-pr

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

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