An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.

Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.

Error:
```
  File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
    res = super().action_post()
  File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
    self._post(soft=False)
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
    move._l10n_cl_create_dte()
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
    folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```

Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.

Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.

Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.

[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8

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

Forward-Port-Of: odoo/odoo#241505

**Steps to reproduce:**
1. Install modules `sale_management` and `l10n_din5008_sale`
2. Go to Settings, Configure Document Layout and set layout to DIN 5008
3. Create a new Sale Order
4. Set a customer, add a product, and fill in the Delivery Date (Other Info)
5. Click on Print and Preview

**Issue:**
The Delivery Date (commitment_date) is not displayed on:
- The DIN 5008 sale order report
- The sale order preview (portal view)

Functional experts confirmed that the Delivery Date must be visible when using the DIN 5008 layout.

**Cause:**
The `commitment_date` field was not included in the DIN 5008 sale order report template nor in the preview view.

**Solution:**
This commit adds the Delivery Date information to:
- The DIN 5008 sale order report template
- The sale order portal/preview view

**opw-5490651**

**Before:**
<img width="560" height="145" alt="image" src="https://github.com/user-attachments/assets/fb29cda1-d668-4682-aa04-12c613f248d8" />
<img width="861" height="268" alt="image" src="https://github.com/user-attachments/assets/615f259f-e0ff-4fb5-9852-1fdd75cda4c9" />

**After:**
<img width="589" height="145" alt="image" src="https://github.com/user-attachments/assets/3f1a8d25-783a-4600-b07e-11b547bb326b" />
<img width="824" height="271" alt="image" src="https://github.com/user-attachments/assets/46b37469-5c72-4556-95e2-eaea0824c166" />

Forward-Port-Of: odoo/odoo#244917

The "Not Sent" filter in Payments list view was not returning the expected records. This was due to an incorrect domain condition in the search view.

This commit updates the filter logic to properly identify payments that haven't been processed or sent, ensuring the filter displays the correct records to the user.

**Description of the issue/feature this PR addresses:**
This PR fixes a bug in the "Not Sent" search filter within the Payment views (Account Payments). Currently, the filter fails to accurately identify and display records that have not been sent, leading to an empty or incorrect list of results regardless of the sending payment's actual status.

**Current behavior before PR:**
When a user applies the "Not Sent" filter in the Payments list view (including both Customer and Vendor payments), the system returns incorrect records or no records at all. This is caused by an inconsistent domain definition that doesn't align with the internal field tracking the "sent" status of the payment.

**Desired behavior after PR is merged:**
The "Not Sent" filter will correctly filter the list to show only those payments where the "Sent" status is not True. This will provide users with an accurate view of pending actions for both Customer and Vendor payments, ensuring consistency across the accounting module.

**Steps to reproduce:**
1. Navigate to the Accounting (or Invoicing) module.
2. Go to Vendors > Payments or Customers > Payments (the issue is global).
3. Ensure there are several payments in the list, some marked as "Sent" and others not yet sent.
4. Click on the Filters dropdown menu in the search bar.
5. Select the "Not Sent" filter.
6. Observe the results: Notice that the list either becomes empty or continues to show records that do not match the "Not Sent" criteria, failing to filter the data correctly.

**video**
https://drive.google.com/file/d/1NTKQ1tHWyZWfs3CPolfDTOMrqaDD9OcN/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#245487

Error message
-----
```
FAIL: TestTourMrpOrder.test_mrp_multi_step_product_catalog_component_transfer
Traceback (most recent call last):
  File "/data/build/odoo/addons/mrp/tests/test_order.py", line 5433, in test_mrp_multi_step_product_catalog_component_transfer
    self.assertEqual(component_transfer.product_uom_qty, 2)
AssertionError: 1.0 != 2
```

Cause
-----
It looks like somehow one of the 2 clicks on the product is either not registered, or the update of the POL's quantity isn't triggered / doesn't happen fast enough, so the tour ends with a quantity of 1 for the product. I see 2 possible causes for this:

1. The product is visible in the initial view. So when the view updates (because of the filtering step), the next step - clicking on the product - the clicks can already be triggered, which might lead to an inconsistent state.
2. There is some synchronicity issue with the quantity update's debounce
https://github.com/odoo/odoo/blob/11292070870ef22663364eda5a4b243dea68856a/addons/product/static/src/product_catalog/kanban_record.js#L16-L18

Solution
-----
Add extra steps to wait for filtering to be applied. Also add extra steps to ensure correct update of the POL's quantity.

-----
Runbot error 237956

Forward-Port-Of: odoo/odoo#243974

### Issue:
Stripe payment is failing in some special currencies (e.g. ISK, UGX).

The issue is already fixed in 19.0; however this commit forwards the test to prevent regressions in future.

#### Steps to reproduce the issue in case the issue exists:
1- Configure Stripe
2- Enable ISK currency
3- Create a SO with ISK currency and generate a payment.
4- Pay using Stripe.

The payment will fail due to the amount mismatch.

### Cause:
Commit https://github.com/odoo/odoo/commit/9493475273a40320228b92940be15ad8cb0643cb added support for special currency but did not adapt amount in validation method.

In stripe payload, we are using `const.CURRENCY_DECIMALS` as `arbitrary_decimal_number` to convert the amount to minor currency unit:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L161-L166

However, not using the same constant in conversion back to major currency unit in `_validate_amount` might cause amount mismatch.

This is currently fixed on 19.0:
https://github.com/odoo/odoo/blob/fbdcb07f50c1c6ba3449afcf41f0144a08413a11/addons/payment/models/payment_transaction.py#L808
https://github.com/odoo/odoo/blob/fbdcb07f50c1c6ba3449afcf41f0144a08413a11/addons/payment_stripe/models/payment_transaction.py#L306-L319

opw-5871420

Forward-Port-Of: odoo/odoo#245689