## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

Forward-Port-Of: odoo/enterprise#121993
Forward-Port-Of: odoo/enterprise#121693

After applying the community fix, a new issue appears in enterprise.

**Steps to reproduce:**
- Install the `l10n_ar_edi` module.
- Go to Customers and create a new customer with:
  - Country: Argentina
  - Identification Type: `Passport`
  - Identification Number: `1234567890a`
  - AFIP Responsibility Type: `Consumidor Final`
- Create a new invoice for this customer with:
  - Journal: `Electronic Invoice (FE)`
  - Document Type: `(6) INVOICES B`
- Try to confirm the invoice.

**Error:**
ValueError: invalid literal for int() with base 10: '1234567890a'

**Expected behaviour:**
For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, 
the identification type must be `DNI` or `CUIL/CUIT`. If another 
identification type is used, the user should receive a proper warning 
instead of a traceback. (see [1])

**Root Cause:**
After the community fix, `_get_id_number_sanitize()` can return an alphanumeric 
value, which is later converted with `int()` at [2] and [3], causing an error.

**Fix:**
This commit adds an explicit validation for Argentinean contacts with 
AFIP Responsibility Type Consumidor Final before converting the 
identification number to an integer, ensuring the user receives the 
proper warning message.

[1]:
https://www.odoo.com/mail/message/1118392033

[2]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798

[3]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931

Related community PR: https://github.com/odoo/odoo/pull/272651

opw-6333998

Forward-Port-Of: odoo/enterprise#124789
Forward-Port-Of: odoo/enterprise#123729

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#125049
Forward-Port-Of: odoo/enterprise#123267