In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated.

To reproduce:
1- Create a product and add quantity on stock.
2- Uncheck `Conitnue Selling` in `Out-of-Stock`
3- Publish the product on the website
4- Create a gift card
5- Add the product to the cart using portal user
7- Using admin user, set the quantity to less than ordered quantity
8- Using portal user, proceed to payment, and use the gift card. Then checkout.
9- As you see, the order is validated

The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`.
However, when checking out with gift card, this method is not called.
To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0)

opw-4941658


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#226126
Forward-Port-Of: odoo/odoo#222306

When changing the expense policy of an expense product, the
compute of analytic distribution of all expenses linked to the product
is triggered.

Steps:

- Have an expense product X with expense policy 'at_sales'
- Create several expenses with an expense product X and  any analytic account
- Create an analytic distribution model that link the expense account of
  X with a specific analytic account AA
- Create a new expense for product X, the analytic account AA should be set
  from the distribution model
- Go to the form view of product x and change the expense policy to
  'cost'
- Go back to the expense list view
-> All expenses having the product X have the AA account

Cause:

`sale_order_id` has been added to the `depends` of `hr_expense._compute_analytic_distribution`
by 2b3bf5e0fe31d4b4ef6b487da493657f695b14e1 but this wrong since we have
the `sale_expense._onchange_sale_order_id` that add the
`analytic_dostribution` field to the fields to be computed.
The compute is triggered since we change `product_id.expense_policy`,
which triggers the `_compute_can_be_reinvoiced` which triggers
the `_compute_sale_order_id`

Fix:

With this commit, we emove the depends on the compute and we also adapt
`test_compute_analytic_distribution_expense` in a way that it triggers the onchange
as we do in the original flow.

opw-4998899

Forward-Port-Of: odoo/odoo#224226

## Versions
17.0+

## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.

## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*

- Go to the Contacts app:
  - Create a new contact:
    - Name: C1;
    - Contacts & Addresses:
      - Delivery Address (Add 2 new addresses):
        - D1;
        - D2.
  - Click the "Sales" action button:
    - Create a new SO for C1 (pre-filled):
      - Invoice Address: C1, D2;
      - Delivery Address: C1, D2;
      - Add any product with:
        - Quantity: 1;
        - Delivered: 1.
      - Create the invoice and confirm it.
- Go back to Contacts and look for C1:
  - Click the the "Sales" action button:
    - Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
  - Create a new SO and select C1 as customer;
  - Delivery Address retrieves "C1, D2" as it is the preferred address.

## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354

## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534

opw-4916381

Forward-Port-Of: odoo/odoo#225189

Steps to Reproduce:
--------------------
- Install the l10n_es_pos module in version 18.0.
- Navigate to Contacts.
- Search for Simplified Invoice Partner (ES) and archive the record.
- Open the Point of Sale (POS) and proceed to place an order.
- Select a product.
- Proceed to the payment screen.
- Choose a payment method and click Validate.

Issue:
---------------------
In version 18.0, when the user proceeds with placing an order, a blank screen appears without any error message,
leading to confusion for the customer.

This issue occurs because during the [pos_load_data](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/models/pos_session.py#L181) process,  while preparing the pos.config, the `simplified_partner_id` is fetched. However, the corresponding `res.partner` record is not included during the preparation of the `res.partner` model data, as the record is archived. As a result, when the system attempts to link the related partner record to `pos.config.simplified_partner_id` on the [JavaScript side](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/static/src/app/models/related_models.js#L1063-L1131 ), [ref](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/static/src/app/models/related_models.js#L1114)
 the simplified_partner_id remains undefined. This eventually leads to an error when attempting to access [simplified_partner_id.id](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/l10n_es_pos/static/src/overrides/models/pos_store.js#L8)  and will lead to the blanck screen

video ref: https://drive.google.com/file/d/1oG6bBIWxhlvnJAgj22hEVtlW0hr8_1eU/view?usp=sharing
```text
Other Approaches:
- We can override the _load_pos_data method and append the simplified partner to ensure it's included during the data loading process.
- Instead of showing a blank screen, we can display an alert message informing the customer to unarchive the simplified partner and proceed with the flow.
`I’m open to any suggestions or alternative approaches that would be the best way to handle this.`
```

OPW: 4953896

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#221150

In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations.

To reproduce the bug:
1- Create a db with, stock, mrp, sale installed.
2- Unarchive `MTO` route.
3- Set `Security Lead` Time in Setting.
4- Create two warehouses wh1, wh2.
5- In wh1, set `Manufacture to Resupply` to True.
6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1.
7- Create a product and track inventory.
8- Create a BOM for the product.
9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product.
10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote.
11- Open MO. Security lead time is considered twice in dates calculations which is mistake.

To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected.

This issue is reproduced because this condition is not sufficient to ensure it is called once:
https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657

The above condition is written to ensure we are adding the delay only when move location is warehouse stock location.

This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2.

To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location.

related: #112325

opw-4889642

Forward-Port-Of: odoo/odoo#224232

Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect:
- someone connected in production does not necessarily have a registration on the test network, therefore the database is in an inconsistent state, and calls to the test network are very likely to fail
- if you create a new connection to Peppol on a neutralized database, since the system parameter was not changed, the new connection was on production

After this commit:
- existing connections are switched in `demo` where everything is mocked locally, no call to the network (whether it's `test` or `prod` can happen)
- the system parameter is switched to `test`, therefore new connections will register to the Peppol test network
- Also added some fields on the Edi Proxy User to display the mode of the user, as well as the proxy_type in list view.
(Those records are only accessible in debug already.)

<img width="579" height="333" alt="image" src="https://github.com/user-attachments/assets/87847726-d954-4f68-8336-07771747365f" />

task-none (report from PMAX + WTA)

Forward-Port-Of: odoo/odoo#226435

### Steps to reproduce:
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner
- Pay with "Swiss ISO20022"
- Create a batch payment with that payment and validate
- In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId))

### Cause:
The code directly inputs the value of `clearing_number` in `ClrSysMmbId`.

### Solution:
Add `MmbId` to contain the clearing number.

### Note:
The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`.

This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations.

opw-4872507

Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
  - 0.049216958195 for day 1
  - 0.053418803419 for day 2
- Create an invoice in USD as follows:
    - line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI

Issue: Payment validation will fail with error

Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862

This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.

opw-4750981

Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768