### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their procure_method during the `_action_confirm`:
https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513
In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call:
https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075
It will therefore also automatically create and run a procurment that will in turn modify the current PO.

opw-4633920

[IMP] account_accountant: limit models to show in bank reco widget

We should only show reco models that should be applicable on the lines.
And so, checking the partner/label/... so they match the values that
are set on the reco model (or they are left empty on the model).

We also moved this part to the new service.

[FIX] account_accountant: applying counterpart with partner + account

Before this commit, applying a reconciliation model with a counterpart
that has a partner and an account would never apply the partner.
It's counterintuitive.

If you apply a model that creates that counterpart, you would expect this
partner to be put on the line.

[FIX] account_accountant: Limit models visible on wizard

Before, only button reconciliation models were visible in the manual
reconciliation wizard.
This filter was removed as the button mode got removed but we still
don't want every model to be visible.
So now, we filter the reconciliation models shown there based on the
partner and the amount.

Also removed some fields that don't exist on the reconciliation widget anymore to avoid traceback.
We will need to decide later what to do with the to_check field

task-4760590

Forward-Port-Of: odoo/enterprise#85455

The _compute_l10n_mx_edi_cfdi_cancel_id method is calling the following search

https://github.com/odoo/enterprise/blob/fd01cf3d57109424725727d7eb40afbe34ef67a9/l10n_mx_edi/models/account_move.py#L685-L691

```python
    move.l10n_mx_edi_cfdi_cancel_id = move.search([
        ('l10n_mx_edi_cfdi_origin', '=like', f'04|{move.l10n_mx_edi_cfdi_uuid}%'),
        ('company_id', '=', move.company_id.id)],
        limit=1,
    )
```

It is generating the following sql query

```sql
    SELECT id
    FROM account_move
    WHERE l10n_mx_edi_cfdi_origin :: text LIKE '04|55555-5555-5555-5555-555%'
        AND company_id = 1
    ORDER BY date DESC, 
        name DESC, 
        invoice_date DESC, 
        id DESC 
    LIMIT 1
```

Running a analyze for a database with ~7M of `account_move` records the result is

```txt
    Limit  (cost=73029.67..137055.68 rows=1 width=26) (actual time=1610.419..1637.035 rows=0 loops=1)
    ->  Incremental Sort  (cost=73029.67..649263.71 rows=9 width=26) (actual time=1600.475..1627.091 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Presorted Key: date
            Full-sort Groups: 1  Sort Method: quicksort  Average Memory: 25kB  Peak Memory: 25kB
            ->  Gather Merge  (cost=1000.46..649263.30 rows=9 width=26) (actual time=1600.466..1627.082 rows=0 loops=1)
                Workers Planned: 2
                Workers Launched: 2
                ->  Parallel Index Scan Backward using account_move__date_index on account_move  (cost=0.43..648262.24 rows=4 width=26) (actual time=1586.469..1586.469 rows=0 loops=3)
                        Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
                        Rows Removed by Filter: 2274213
    Planning Time: 0.197 ms
    JIT:
    Functions: 13
    Options: Inlining false, Optimization false, Expressions true, Deforming true
    Timing: Generation 3.044 ms, Inlining 0.000 ms, Optimization 2.327 ms, Emission 34.202 ms, Total 39.574 ms
    Execution Time: 1637.815 ms
```

PostgreSQL query stats from production returns the following top 1 slow query

```txt
Total Time  Average Time   Calls
4,981 min   1,351 ms       221,238
    SELECT "account_move"."id"
    FROM "account_move"
    WHERE (("account_move"."l10n_mx_edi_cfdi_origin"::text LIKE $1)
            AND ("account_move"."company_id" = $2))
            AND (("account_move"."company_id" IN ($3)) OR "account_move"."company_id" IS NULL)
    ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
    LIMIT $4
```

Creating the following index

```sql
    CREATE INDEX account_move_l10n_mx_edi_cfdi_origin_index
        ON account_move (l10n_mx_edi_cfdi_origin)
        WHERE l10n_mx_edi_cfdi_origin IS NOT NULL
```

Similar to define the field `account_move.l10n_mx_edi_cfdi_origin(index='btree_not_null')`

The same query analyze result is

```txt
    Limit  (cost=4.49..4.49 rows=1 width=26) (actual time=0.018..0.018 rows=0 loops=1)
    ->  Sort  (cost=4.49..4.51 rows=9 width=26) (actual time=0.017..0.017 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Sort Method: quicksort  Memory: 25kB
            ->  Index Scan using account_move_l10n_mx_edi_cfdi_origin_index on account_move  (cost=0.42..4.44 rows=9 width=26) (actual time=0.011..0.012 rows=0 loops=1)
                Index Cond: (((l10n_mx_edi_cfdi_origin)::text >= '04|55555-5555-5555-5555-555'::text) AND ((l10n_mx_edi_cfdi_origin)::text < '04|55555-5555-5555-5555-556'::text))
                Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
    Planning Time: 0.147 ms
    Execution Time: 0.036 ms
```

It is ~9k times faster

Forward-Port-Of: odoo/enterprise#85427

This is a fix-of-fix.

#### Explanation of the first fix

Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used.

However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice.

To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice.

However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future).

#### The fix-of-fix (this PR)

To solve both those issues, here is what we do:
- now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change).
- if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too.

task-none

Forward-Port-Of: odoo/enterprise#85136

The aim of this commit is to:
    - avoid reporting negative amount in a 281.50 form which are rejected by the administration.
    - avoid reporting form with 0 value everywhere which are rejected by the administration.
    - avoid reporting a form with an amount < 250 EUR

Context:
The administration stated that we don't need to make any report that would be above 250 EUR.
(art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92)

https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50 https://travaillerensociete.indicator.be/main/newsadvice/52784/news/52785/news_story/533/ https://www.monastucesetconseils.be/2025-04/fiches-fiscales-281-50-pour-le-29-juin-2025-WAACPCAR_EU33150802

Before this commit:
Odoo could create a form with a negative amount as commission/fee/... This could result in the administration software converting the xml into a BOW file to generated an error and a file that will be rejected by Belcotax.
Same for form with 0 everywhere.

Also, accountants always end up deleting the 281.50 form below 250 EUR as those don't need to be reported.

After this commit:
Odoo don't report negative or null total amount as commission/fee/... and doesn't create any form if the total amounts are below 250 EUR saving accountants the burden to remove them.

task-id: None
This was discussed and done with TSB and DELC and is also the result of our past experiences reporting 281.50 forms which also involved CAHE, MAKR and CAL.

Forward-Port-Of: odoo/enterprise#85508

When timezone of user is empty and the user clicks on Add Closing Day(s) button,
a traceback will appear.

Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install ``Appointments``
- Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s)

Traceback:
```
File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda>
    leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
  File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
    user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
  File "/home/odoo/src/odoo/odoo/_monkeypatches/pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
AttributeError: 'bool' object has no attribute 'upper'
```

https://github.com/odoo/enterprise/blob/2c938b66fc1b526a360f4b199a47bcc53991bcb9/appointment/wizard/appointment_manage_leaves.py#L14
When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.

Forward port https://github.com/odoo/enterprise/pull/64948 was closed in master,
so the issue is still present in saas-17.4 and all later versions.

sentry-6537084290

Forward-Port-Of: odoo/enterprise#83363

Versions
--------
- 17.4+

Steps
-----
1. Configure UoM decimal accuracy to be 0 digits;
2. create, confirm a SO;
3. create a downpayment invoice;
4. go back to the SO;
5. modify the product line's price.

Issue
-----
> AssertionError: precision_rounding must be positive, got 0.

Cause
-----
When checking for quantity changes to log on `write`, a fallback rounding value is retrieved using `precision_get`. This returns a `precision_digits` value, but is being used as a `precision_rounding` value, resulting in an error when it is 0.

In previous versions, this fallback value was never used, as `display_type` lines were skipped, and any other line is guaranteed to have a `product_uom.rounding` value.

As of 9aa52dd6418e, the constraint was changed for `is_downpayment` lines not having to be of `display_type` nor require a `product_uom` value, meaning the faulty fallback value now gets used.

Solution
--------
Remove the fallback value, and only log lines with a `product_uom` value.

opw-4566621

Forward-Port-Of: odoo/odoo#205581

**Steps to reproduce:**
- Install l10n_it_edi_ndd
- Switch to an Italian company (e.g. IT Company)
- Create an invoice
- Confirm the invoice
=> Document Type (in "Electronic Invoicing" tab) is computed
- Create a credit note from the invoice
- On credit note wizard, click on "Reverse and Create Invoice"
- Check the created credit note

**Issue:**
The credit note is posted but its Document Type field (l10n_it_document_type) is empty.
l10n_it_document_type should be computed when it doesn't have a value already and the state of the move is "posted".
The credit note will be rejected when sent to SDI because this field is empty.

**Cause:**
In the reverse method, the field is set to False in order to be recomputed.
However, the compute method is triggered when the state changes, but the credit note not is already posted.
Therefore the field will not be recomputed.

**Solution:**
Set the value to False before the creation of the credit note.
So that, the field will be recomputed when posting the credit note.

opw-4689755




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

Forward-Port-Of: odoo/odoo#208654

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.

Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.

We revert the recent commit https://github.com/odoo/odoo/commit/a6787552150434d4366e30cbeb6f6d309c2c6cb9 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.

Forward-Port-Of: odoo/odoo#209960
Forward-Port-Of: odoo/odoo#208876

Another fix is added here:

The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported.

The _compute_l10n_mx_edi_cfdi_cancel_id method is calling the following search

https://github.com/odoo/enterprise/blob/fd01cf3d57109424725727d7eb40afbe34ef67a9/l10n_mx_edi/models/account_move.py#L685-L691

```python
    move.l10n_mx_edi_cfdi_cancel_id = move.search([
        ('l10n_mx_edi_cfdi_origin', '=like', f'04|{move.l10n_mx_edi_cfdi_uuid}%'),
        ('company_id', '=', move.company_id.id)],
        limit=1,
    )
```

It is generating the following sql query

```sql
    SELECT id
    FROM account_move
    WHERE l10n_mx_edi_cfdi_origin :: text LIKE '04|55555-5555-5555-5555-555%'
        AND company_id = 1
    ORDER BY date DESC, 
        name DESC, 
        invoice_date DESC, 
        id DESC 
    LIMIT 1
```

Running a analyze for a database with ~7M of `account_move` records the result is

```txt
    Limit  (cost=73029.67..137055.68 rows=1 width=26) (actual time=1610.419..1637.035 rows=0 loops=1)
    ->  Incremental Sort  (cost=73029.67..649263.71 rows=9 width=26) (actual time=1600.475..1627.091 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Presorted Key: date
            Full-sort Groups: 1  Sort Method: quicksort  Average Memory: 25kB  Peak Memory: 25kB
            ->  Gather Merge  (cost=1000.46..649263.30 rows=9 width=26) (actual time=1600.466..1627.082 rows=0 loops=1)
                Workers Planned: 2
                Workers Launched: 2
                ->  Parallel Index Scan Backward using account_move__date_index on account_move  (cost=0.43..648262.24 rows=4 width=26) (actual time=1586.469..1586.469 rows=0 loops=3)
                        Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
                        Rows Removed by Filter: 2274213
    Planning Time: 0.197 ms
    JIT:
    Functions: 13
    Options: Inlining false, Optimization false, Expressions true, Deforming true
    Timing: Generation 3.044 ms, Inlining 0.000 ms, Optimization 2.327 ms, Emission 34.202 ms, Total 39.574 ms
    Execution Time: 1637.815 ms
```

PostgreSQL query stats from production returns the following top 1 slow query

```txt
Total Time  Average Time   Calls
4,981 min   1,351 ms       221,238
    SELECT "account_move"."id"
    FROM "account_move"
    WHERE (("account_move"."l10n_mx_edi_cfdi_origin"::text LIKE $1)
            AND ("account_move"."company_id" = $2))
            AND (("account_move"."company_id" IN ($3)) OR "account_move"."company_id" IS NULL)
    ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
    LIMIT $4
```

Creating the following index

```sql
    CREATE INDEX account_move_l10n_mx_edi_cfdi_origin_index
        ON account_move (l10n_mx_edi_cfdi_origin)
        WHERE l10n_mx_edi_cfdi_origin IS NOT NULL
```

Similar to define the field `account_move.l10n_mx_edi_cfdi_origin(index='btree_not_null')`

The same query analyze result is

```txt
    Limit  (cost=4.49..4.49 rows=1 width=26) (actual time=0.018..0.018 rows=0 loops=1)
    ->  Sort  (cost=4.49..4.51 rows=9 width=26) (actual time=0.017..0.017 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Sort Method: quicksort  Memory: 25kB
            ->  Index Scan using account_move_l10n_mx_edi_cfdi_origin_index on account_move  (cost=0.42..4.44 rows=9 width=26) (actual time=0.011..0.012 rows=0 loops=1)
                Index Cond: (((l10n_mx_edi_cfdi_origin)::text >= '04|55555-5555-5555-5555-555'::text) AND ((l10n_mx_edi_cfdi_origin)::text < '04|55555-5555-5555-5555-556'::text))
                Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
    Planning Time: 0.147 ms
    Execution Time: 0.036 ms
```

It is ~9k times faster

Forward-Port-Of: odoo/enterprise#85427

Steps to reproduce:
(thanks to TBS for investigating + writing the test)

1. Have a MX company with Quadrum or SwSapien
2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN`
3. Create a USD invoice for `13220.00 USD` and send CFDI
4. Reconcile transaction and invoice
5. Click "Update payments" on the invoice => CRP20211

Looks like it comes from this rounding difference

Rate is computed by odoo using
`305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

PAC verify the amount paid using
`13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN`

Solution:
There is no solution by adapting the rate:
- quadrum restricts the rate to 6 decimals;
- rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`.

So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly
`round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`.

In tests, both Quadrum and SwSapien seem to accept this.

We don't perform the modification for Solucion Factible (the other PAC).

opw-4222310

Forward-Port-Of: odoo/enterprise#85602
Forward-Port-Of: odoo/enterprise#83499

## Version:
17.0+

## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.

## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
  - Set `Invoice Date` to the same date as the subscription;
  - Confirm and go to the invoice's preview and start payment process:
    - Use a new card for payment;
    - Check `Save my payment details` checkbox and pay.

## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220

## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.

opw-4654142

Forward-Port-Of: odoo/enterprise#85554
Forward-Port-Of: odoo/enterprise#85314