Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237)

---

There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session.

In addition, if a session is already open, it is no longer possible to resolve the situation:

* From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method.
* From `pos.config`: the payment methods field is read-only when there is an open session.

We had to delete one of the online payment methods from the database directly to be able to open the POS session again.

To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method.

Forward-Port-Of: odoo/odoo#240343

Whenever an error occurs during the ZATCA onboarding steps—such as
providing a company name that exceeds 127 bytes in binary representation
(for example, 64 Arabic characters without whitespace result in exactly
127 bytes; see refs [1] and [2])—the system returns a traceback to the
user instead of a clear and user-friendly error message.

Error:
`TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'

This is due to the check-in `_l10n_sa_request_production_csid` for an 'error'
key, not present in the response when an OTP is invalid because in these cases,
the `_l10n_sa_call_api` returns the response_data directly.

This fix improves the behaviour by displaying a user-friendly alert message
with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

[1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571
[2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960

sentry-7169834710

Forward-Port-Of: odoo/odoo#242810

Fix an incorrect flow when creating a Manufacturing Order through the Barcode app.

Steps to reproduce:
- Disable tracking in Settings
- Create a BOM for product Table with components Wood and Screws
- In the Barcode app, go to Manufacturing
- Click New > Add product and select Table
- Click Confirm -> Components are not added after the Table line

The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected.

This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`.

This fix ensures that `lot_producing_id` is defined before performing the comparison.

opw-5165163

Forward-Port-Of: odoo/enterprise#103619
Forward-Port-Of: odoo/enterprise#98440

Processing a buy-receive-bill process in a foreign currency and with
an auto-standard product will lead to an incorrect valuation

To reproduce the issue:
(Company in USD)
1. Enable EUR and define the rates as followed:
   - Yesterday: 2
   - Today: 2.5
2. Create a product category:
   - Method: Standard
   - Valuation: Automated
3. Create a product P in that category
   - Cost: 10 USD
4. [Yesterday] Confirm a PO in EUR with 1 x P
5. [Yesterday] Receive it
6. Bill

Error: the stock valuation has two entries: one with 10 USD debit, the
receipt. Another one with 2 USD credit, the currency exchange rate
difference. The second one is a mistake, in a standard configuration,
the stock valuation should be impacted by nothing but the cost defined
on the product form.

Since [1], in some conditions the method `_get_exchange_account`
returns the stock valuation account. This is what happens here, but
it's a mistake since in the above case, we should stick with the
classic account (i.e. the `super` call). The conditions must be more
strict.

[1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7

OPW-5380665

Forward-Port-Of: odoo/odoo#243094
Forward-Port-Of: odoo/odoo#243029