### 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

**Problem:**
The value of a move does not take the correct currency rate if it 
was changed manually on the invoice.

**Steps to reproduce:**
- make sure dollar is your main currency 
- activate euro and set a rate of 1 USD -> 2 euros
- create an avco perpetual storable product with no tax
- confirm a purchase order for 1 product at 100 euros with no tax
- validate move
- create a bill for this purchase order
- set the currency to euro 
- below 'EUR' change the currency to 4 
(the bug also happens if you open the widget calendar and 
select a date with another rate than the invoice date) 
- in the journal items tab you should see the value going 
from 50 to 25 for the account move lines.
- confirm the invoice
- open stock and search your product 

**Current behavior:**
the unit price is 50 

**Expected behavior:**
it should be 25

**Cause of the issue:**
In _get_value_from_account_move when computing the value, 
we convert the value of the account move line using the _convert 
method on the currency at the date of the 
invoice, but if the rate was changed manually this is no longer correct. 
https://github.com/odoo/odoo/blob/4ad397e94b4661cd64515e137b3e650dc330269c/addons/purchase_stock/models/stock_move.py#L170

**fix**
When manually changing the rate on the widget, the account move lines 
are updated using currency_rate 
https://github.com/odoo/odoo/blob/8d7194128b26a09be75bf5bfe4e63c8bbfaac69f/addons/account/models/account_move_line.py#L1634
Using the same compution for the valuation of the move ensures
alignment.

currency_rate is computed based on invoice_currency_rate which 
is updated in case the rate was set manually.
https://github.com/odoo/odoo/blob/4ad397e94b4661cd64515e137b3e650dc330269c/addons/account/models/account_move_line.py#L726

opw-5416654

Forward-Port-Of: odoo/odoo#245714

*: payment{,_adyen,_mercado_pago,_stripe}

### Issue:
The payment in some payment providers are failing to due setting
currency decimals.

#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
   to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through Adyen. As you see payments fail.

### Cause and Fix:
This issue is the same as https://github.com/odoo/odoo/pull/245059. That fix only focused on Stripe, however, the same issue is reproducible on other providers e.g. `Adyen`. In order to avoid the same issue, we can have a general fix to round down all payment transaction amounts to currency's minor unit in `_validate_amount_and_currency`.

---

There is another issue in Mercado Pago which the if currency is not one of these currencies then it will not be sent to provider rounded:
https://github.com/odoo/odoo/blob/035b701cbf7bd654f56f07244e606e4038c4115a/addons/payment_mercado_pago/const.py#L39-L43

Mercado Pago rounds **up** in these cases, which will cause mismatch in `_validate_amount_and_currency`.

opw-5871470

Forward-Port-Of: odoo/odoo#248320
Forward-Port-Of: odoo/odoo#245877

Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.

ValueError is raised:
```py
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.

Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.

tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)

Forward-Port-Of: odoo/enterprise#107477

## Short functional explanation of the error
In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs.

## Reproduction Steps
1. Go to Timesheets.
2. Click on the Reporting tab > By Billing type.
3. Click on the search bar and click on Employee under the Group By section.

### Expected behavior
A report shows the different hours worked on billing time for each employee.

### Unexpected behavior
An error occurs:
```TypeError: data.forEach is not a function```

## Origin of the issue
When retrieving the data to show in the report after having grouped
it by employee, this piece of code is called:
https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/sale_timesheet_enterprise/static/src/views/timesheet_analysis_pivot/timesheet_analysis_pivot_model.js#L23-L36
However, the variable (data) on which we perform the forEach isn't
an array: it's an object of structure:
```
{ "group": { "rowValues": [], "colValues": [] }, "rowGroupBy": [ "employee_id" ], "colGroupBy": [], "subGroupIndex": 2, "subGroups": [ { "employee_id": [ 1, "Administrator" ], "__extra_domain": [ [ "employee_id", "=", 1 ] ], "unit_amount:sum": 0, "__count": 2, "__domain": [ "&", [ "project_id", "!=", false ], [ "employee_id", "=", 1 ] ] } ] }
```
on which we can't perform a forEach. The data we want to access to
use in the report is actually the `subGroups` element of data.

__
opw-5910036

Forward-Port-Of: odoo/enterprise#106969