This commit adds an index on `(journal_id, date)` to speed up `_get_last_sequence_domain`.

The slow part is

`.search(domain, order='date [desc|asc]', limit=1)`

Because of the order by date, postgresql scans the index on `date`, assuming a row will be quickly matched.

If this assumption is wrong though, it'll scan a large part of the index or all of it, which is slow.
This is the case with account move 17102258 on odoo.com at the time of writing this.

- before
   - 1st query https://explain.dalibo.com/plan/6b8ff62b1572ah1a
   - 2nd query https://explain.dalibo.com/plan/41243cgccg5798gb
- after
  - 1st query https://explain.dalibo.com/plan/4fd2c7ed28g7b138
  - 2nd query https://explain.dalibo.com/plan/2heh6c6965c88h71
  - ~~1st query https://explain.dalibo.com/plan/f874a31f4b07hdeb~~
  - ~~2nd query https://explain.dalibo.com/plan/e8h09725gfh4c2e9~~

full `web_read`
- before ~1min 10s
- after ~650ms

task-6481393



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

Forward-Port-Of: odoo/odoo#283159

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had 2081 orders).
3. Close the session.

The close takes several minutes, and on a remote database the request is killed by the worker time limit before it completes.

Cause
-----
`_reconcile_account_move_lines` reconciles each group of lines with its own `reconcile()` call, one per payment. Every call creates its partials and triggers the recompute cascade of the ORM, which searches `account.move.line` over the whole set of payments of the session, so the cost of a single call grows with the number of payments.

`_create_invoice_receivable_lines` has the same shape: the values are grouped per payment, so every group holds a single value and the lines are created one `create()` call at a time.

opw-6242303 already batched the creation and the posting of the split bank payments, and the reconciliation of their receivable lines, but only for the orders that are not invoiced. Invoiced orders go through `split_inv_payment_receivable_lines`, which was left untouched.

Fix
---
Gather every reconciliation of the session into a single `_reconcile_plan` call. The entries of the plan are processed independently and in order, so the result is the same as reconciling them one by one, but the recompute cascade runs once instead of once per payment.

Create all the invoice receivable lines in a single `create()` call and dispatch the records back to their payment method or payment afterwards.

Benchmark
---------
Closing a session of 2081 invoiced orders on a copy of the customer database:
- before: 558s
- after: 54s

opw-6458271

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

Forward-Port-Of: odoo/odoo#284783
Forward-Port-Of: odoo/odoo#281495

Issue:
---
Due to this issue, generating PDF Quote using Quote Builder with dynamic fields leads to a traceback.

This was partially fixed by: e16edc7b0d9f56cb7769068ecf7d64ff8b0f6359

Steps:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quote builder tab, select a document. This document should have dynamic fields. e.g. you could use`Office Furnitures Header` document.
4- Print -> PDF Quote.

Cause:
---
In previous fix, we fixed the traceback when no dynamic field is set. However, if you have a dynamic field, then inside
`PdfWriter._update_field_annotation()`, the font is get from `DR` dict inside acroform:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L917-L929
Even if we are not setting a font, we need to have an empty `DR` dict inside acroform, in order to avoid calling `get` on a none object, which is leading to the traceback.

Also in previous fix we were losing `NeedAppearances` inside `AcroForm` by creating new dict which wasn't right.

opw-6392001

Forward-Port-Of: odoo/odoo#278881

**Steps to reproduce:**
- Create a SO and add the Event Registration - Standard product and specify an event
- Confirm the SO then select "Create/Update registrations"
- Cancel the SO, then "Set to Quotation"
- Select "Preview" and confirm the Sale Order again
- There will not be any new registration created when there should be one.

**Behavior:**
Usually when a sale order is confirmed the `action_sale_order_event_registration` form will be opened which when filled correctly creates registrations. However in certain cases: confirming from the customer portal, or simply closing the form when it is opened, will not trigger `action_make_registration` which creates registrations if it is not already the case

`action_confirm()` should be creating the registrations correctly on its own anyway by calling ´init_registrations()´ : https://github.com/odoo/odoo/blob/beed378cde592bc96c1e79a976ac775264b843ed/addons/event_sale/models/sale_order_line.py#L49-L66

This function tries to create each missing registrations by looking at the amount in the so_line and deducting the already created registrations, however since some of them can be cancelled, this computation is wrong. And leads to registration not being created when they should.

opw-6444127

Forward-Port-Of: odoo/odoo#280426

Issue:
When a user selects a generic appraisal template other than the first one, confirming or resetting the appraisal silently replaces that selection with the first generic template. Filtering appraisals by the originally selected template then fails to return the appraisal.

Steps to reproduce:
* Configure multiple appraisal templates without department restrictions.
* Create an appraisal and select a template other than the first one.
* Confirm the appraisal.
* Filter appraisals by the selected template.

Cause:
`_compute_appraisal_template()` only preserved templates directly linked to the appraisal's department. Generic templates have no department relation, so a valid selected template was discarded whenever the computation was triggered by a state dependent department recomputation. The generic fallback then stored the first template instead.

https://github.com/odoo/enterprise/blob/5c57ccbb13269af28de0a6c7f35454be52424f43/hr_appraisal/models/hr_appraisal.py#L195-L209

Solution:
We need to distinguish the generic default loaded on an unsaved form from a compatible generic template already stored on an appraisal. Preserve the latter across recomputations while retaining department template priority during creation and rejecting templates that no longer match the appraisal's department or company.

opw-6449041

Forward-Port-Of: odoo/enterprise#127566

Issue:
When creating an asset using an "154.01.01 Vehicles", the depreciation values of the journal entries created are zero

Steps to reproduce:
1. Install l10n_mx and enter a Mexican company
2. Create an asset and setting the fixed asset account as 154.01.01 Vehicles
3. Click on "Compute Depreciation" and in the "Depreciation Board" page, all the journal entries created will not have any depreciation values

Cause:
In the l10n_mx chart of accounts, all accumulated depreciation accounts are set as "expense_depreciation" whereas they should be asset accounts because accumulated depreciation accounts are used to credit asset accounts to decrease asset values. If an account of type "expense_depreciation" is used, then when the depreciation account is credited and the expense account is debited, all financial events will occur within expense accounts, which is why no depreciation values were recorded as the asset balances stay the same. Additionally, the "asset_depreciation_account_id" field on "account.account" has a domain restricting selection to "account_type" of "asset_fixed" or "asset_non_current"

Solution:
Change the "account_type" of l10n_mx accumulated depreciation accounts from "expense_depreciation" to "asset_fixed" and l10n_mx accumulated amortization accounts from "expense_depreciation" to "asset_non_current"

Updrade PR: [odoo/upgrade/pull#10936](https://github.com/odoo/upgrade/pull/10936)

opw-6359618

Forward-Port-Of: odoo/odoo#278185

### Description of the issue/feature this PR addresses:
Fixes an issue where timesheets lose their invoice reference when reversing and re-creating an invoice via a credit note.

### Current behavior before PR:
When reversing an invoice tied to timesheets and creating a replacement via a credit note, the timesheets linked to the original invoice have their timesheet_invoice_id cleared. Because the modify_moves function builds the replacement invoice directly via copy_data()/create(), it bypasses the normal sale order invoicing flow. As a result, the unbilled timesheets are left permanently unlinked from the newly created invoice, leaving the new invoice with no reference to the timesheets linked to the original sale order.

### Desired behavior after PR is merged:
When a replacement invoice is created, each timesheet is properly relinked to the corresponding line on the new invoice. This linkage matches on the sale order line (so_line) rather than line position, ensuring accuracy since line order and count are not guaranteed to be preserved between the original and modified invoices.

opw-6449995

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

Forward-Port-Of: odoo/odoo#283104

When a user manually sets a price on an optional line (overriding the pricelist), and then changes the quantity in the portal preview, the manual price is lost and gets reset to the pricelist price.

Steps to reproduce:
---
- Install Sales module and enable Pricelists.
- Create a product with qty-based pricelist rules:
   - min qty: 1  → price: 100
   - min qty: 10 → price: 80
- Create a quotation with an optional section containing this product.
- Manually change the product price to 150 (overriding pricelist).
- Mark the section as optional and preview the quotation.
- Change the quantity to 10 in portal preview.

Issue:
---
- The manually set price (150) is incorrectly reset to the pricelist price (80).

Root cause:
---
- After [commit], if there is no config parameter set and if there is an active pricelist, we simply call `_reset_price_unit()` without checking whether the price was manually set or not.
- Additionally, `_reset_price_unit()` calls `update()` which writes `price_unit` and `technical_price_unit` one by one as separate `write()` calls. The `write()` method has a guard([1]) that strips a lone `technical_price_unit` write unless `sale_write_from_compute` is set in context. Without this flag, `technical_price_unit` is silently discarded, causing it to drift from `price_unit`. On the next qty change, this mismatch is detected as a manual price, permanently blocking further pricelist updates.

Solution:
---
- Check whether the price was manually set before calling `_reset_price_unit()`, and pass `sale_write_from_compute=True` in context so both `price_unit` and `technical_price_unit` are written correctly.

[commit]: https://github.com/odoo/odoo/commit/93b6bdd6a4909bc0b45b90ab6a2d0734a218292d
[1]https://github.com/odoo/odoo/blob/fffd987cc98d1ea0cd04e24dda2ed8b64a219cdc/addons/sale/models/sale_order_line.py#L1391-L1399

opw-6426634

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

Forward-Port-Of: odoo/odoo#281107

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

After this [commit], companies outside the EU can use European VAT numbers.
Consequently, an Argentine partner can have a CUIT number such as ``BE0477472701``,
which is valid as a Belgian VAT number but not as a CUIT.
When printing the invoice, the ``l10n_ar_vat`` field is computed
from the partner's VAT and its value is passed to ``int()``,
causing a traceback at the following line:
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[commit]: https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0

Enterprise PR: https://github.com/odoo/enterprise/pull/127820

sentry-7666042143

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

Forward-Port-Of: odoo/odoo#282454

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

The issue occurs because when the partner's identification type is CUIT,
At [1] ``_run_check_identification()`` method does not include partners whose identification type has ``is_vat=True``.
As a result, CUIT is not validated by ``_run_check_identification()`` method in ``l10n_ar`` module at [2].
So, partner's ``l10n_ar_vat`` field can be computed as ``BE0477472701``.
Passing this value to ``int()`` raises the traceback during invoice printing at below line.
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[1]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_latam_base/models/res_partner.py#L24-L30

[2]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_ar/models/res_partner.py#L55-L65

Community PR: https://github.com/odoo/odoo/pull/282454

sentry-7666042143

Forward-Port-Of: odoo/enterprise#127820

**Description of the issue/feature this PR addresses:**

When importing a SODA XML file, users without the Analytic Accounting
group encounter an access rights error even if Analytic Accounting is not
enabled.

This occurs because the import wizard reads the `analytic_account_id` field
on the `soda.analytic.mapping` model to build an internal dictionary of
departments. Because this field is restricted to the Analytic Accounting
group, the evaluation of this field crashes the import for users even when
the Analytic Accounting feature is disabled.

This commit resolves the issue by using `.sudo()` on the analytic mapping
recordset to bypass the field-level group restriction.

**Steps to reproduce:**

- Log in as Mitchell Admin, change company to “My Belgian Company”
- Settings > Users & Companies > Users > Mitchell Admin > Access Rights > Extra Rights > ensure “Analytic Accounting” is unchecked
   - Also ensure Mitchell Admin is not part of the “Analytic Accounting” group
- Accounting Dashboard > remove “Favorites” from filter > drag & drop a SODA XML file to “Miscellaneous Operations” > save > observe Access Error


**Current behavior before PR:**

- Users who don't belong to the Analytic Accounting group encounter an access error when attempting to import SODA XML files, even when the Analytic Accounting feature isn't enabled

**Desired behavior after PR is merged:**

- Those users no longer receive an access error

opw-6376039

Changing a project's visibility fails when its documents folder contains a shortcut.
The visibility change is never applied and the following error is raised:
"You can not update the access of a shortcut, update its target instead."

### Reproduction steps

- Create a project and add a document to its folder.
- Create another document outside the project's folder.
- Create a shortcut to that document in the project's folder.
- Change the project's visibility.

### Cause

Changing a project's visibility updates the access rights of its folder and documents together.

The shortcut access check is meant to reject operations performed only on shortcuts. However, reading `shortcut_document_id` on a recordset returns the shortcut targets found across that recordset. Therefore, the presence of a single shortcut makes the check reject the whole operation.

This prevents regular documents and the project folder from having their access updated.

### Fix

Only reject access updates when all records involved are shortcuts.

This preserves the protection against changing shortcut access directly while allowing project access updates to include shortcuts alongside regular documents and folders.

opw-6472637

Forward-Port-Of: odoo/enterprise#129448
Forward-Port-Of: odoo/enterprise#128756

Step to reproduce:
 - create a faulty token that won't work and link it to a subscription
 - launch the recurring invoice cron
 - the following traceback occurs

```
last_tx_sudo = (self.transaction_ids - existing_transactions).sudo()
```

When the payment fails, the system rollback and we store the last_tx_sudo value in a dedicated variable. After rollback, the record does not exists anymore. Therefore, accessing the value fails.

```
  File "/home/odoo/src/enterprise/saas-18.2/sale_subscription/models/sale_order.py", line 1703, in _handle_automatic_invoices
    if not last_tx_sudo or last_tx_sudo.renewal_state in ['pending', 'authorized']:
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1439, in __get__
    self.compute_value(record)
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1603, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 4575, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 69, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-18.2/sale_subscription/models/payment_transaction.py", line 25, in _compute_renewal_state
    if tx.state in ['draft', 'pending']:
       ^^^^^^^^
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1406, in __get__
    raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
```

Moreover, since https://github.com/odoo/enterprise/pull/45236/files#diff-c36fd7952cc2bef40716419a668de41963d49e1aa4177d9319d503fc260da588R1678-R1682

```
if not last_tx_sudo or not last_tx_sudo.renewal_state not in ['pending', 'authorized']:
```

has become

```
if not last_tx_sudo or last_tx_sudo.renewal_state in ['pending', 'authorized']:
```

But it feels strange to unlink the invoice when the payment succeed.


This PR fixes it.

Forward-Port-Of: odoo/enterprise#83913

### Issue:
When moves share the same `sequence_number` in a journal but have different suffixes (e.g. `INV/2026/00010` and `INV/2026/00010A`), the `made_sequence_gap` flag was incorrectly set

### Cause:
`_update_sequence_made_gap`, introduced in commit https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac selects the previous and next moves ordered by `sequence_number` without filtering by suffix

This causes two issues:
- Moves from different suffix sequences are used as neighbors, leading to incorrect gap detection
- Duplicate `sequence_number` values across suffixes are not accounted for, so only one move is considered per number

### Steps to reproduce:
- Install `account`
- Post 12 invoices to get a sequence up to `INV/2026/00012`
- Reset `INV/2026/00012` to draft, rename it to `INV/2026/00010A`
- Reset `INV/2026/00010A` to draft, rename it to `INV/2026/00009A` and confirm
Before the fix: `INV/2026/00011` is red
Expected: `INV/2026/00011` should not be red because `INV/2026/00010` exists
- Delete `INV/2026/00009`
Before the fix: `INV/2026/00010` is red
Expected: `INV/2026/00010` should be red (gap in no-suffix sequence)
- Reset `INV/2026/00009A` to draft and confirm it again
Before the fix: `INV/2026/00010` is not red
Expected: `INV/2026/00010` should still be red (different suffix)

### Notes:
Suffix changes are treated as distinct sequences following the same gap rules as any other sequence
This was agreed with R&D — the gap flag is meant to signal inconsistencies within a sequence, not across suffixes

opw-6454823

Forward-Port-Of: odoo/odoo#282503

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1

### Cause of the issue:

This is the exact use case already fixed in
85dd3369ed17b98b2ce485be04f140cf4cfa8aa3, which stamped the finished move with a `location_final_id` pointing at WH/Stock so that the move contributes to the forecast there even though its `location_dest_id` is the intermediate WH/Post-Production.

That fix was reverted in practice by 42275f83dc5350822a625e19d65148e8b41ab1d4, which replaced the value with `mo.location_dest_id`:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_move.py#L466-L467

Its reasoning was that in a single-warehouse setup `location_dest_id` equals the warehouse stock location, so the behaviour would be unchanged. That holds in 1 and 2 steps, where the extra step is on the component side and only moves `default_location_src_id` to the pre-production location. It breaks in 3 steps, the only mode that also moves `default_location_dest_id`, to the post-production location: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L246-L247 and `_compute_locations` propagates it to the MO:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/mrp_production.py#L334-L341

WH/Post-Production is a sibling of WH/Stock under the warehouse view location, not a child of it. Since `location_final_id` takes precedence over `location_dest_id` for the non-done part of the move chain:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L331-L334 the finished move stopped being counted in the WH/Stock forecast.

Why the test did not catch it:

`test_3_steps_manufacturing_forecast` stayed green through the whole regression, because it scoped `virtual_available` with a `location_id` context key. `_get_domain_locations` only reads `location` and `warehouse_id`; `location_id` is silently ignored: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L284-L287 The call therefore fell through to the branch scoping the forecast to every warehouse view location:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L303-L309 and the warehouse view location is the common parent of both WH/Stock and WH/Post-Production. The assertion held regardless of where `location_final_id` pointed, so the test was a false positive from the start: it also passes with 85dd3369ed17b98b2ce485be04f140cf4cfa8aa3 fully reverted. Using the `location` key makes it fail without the fix and pass with it.

### Fix:

Neither fix proposition was right on its own; each one was correct only in its own scenario. The`mo.warehouse_id.lot_stock_id` resolves the warehouse from the components, so it points at the wrong warehouse as soon as the finished product is produced for another one. `mo.location_dest_id` is the post-production location as soon as the warehouse manufactures in 3 steps, so it drops the quantity from the forecast of the manufacturing warehouse itself.

What separates the two is not the warehouse but whether the destination is a transit step. In 3 steps the finished product only reaches the stock through the post-production push rule: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L57 so the final location is the stock of the warehouse owning that destination. Any other destination is already final and is kept as is, which leaves cross-warehouse MOs and destinations set to a sub-location of the stock untouched.

The rule's destination is read rather than `warehouse.lot_stock_id` because a push move takes its destination from the rule and not from the operation type:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_rule.py#L256-L260
so the forecast stays correct when the store step is reconfigured to land somewhere else than the warehouse stock.

The rule is looked up on `pbm_route_id` by its `picking_type_id` instead of through `warehouse.sam_rule_id`, because that field is no longer set. It used to be an entry of `_generate_global_route_rules_values`, and it is that entry which made the generic warehouse machinery create the rule and store it back on the warehouse:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_warehouse.py#L403-L410
11e69870db1c49d9a6af79ffd263e4e162b34b6b removed it when the post-production step stopped being a pull rule on the Manufacture route and became a push rule generated from `get_rules_dict`. Only the field declaration was left behind, and nothing writes it any more:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L21-L22
so reading it would silently give an empty recordset. The lookup is not delegated to `_get_push_rule` to avoid a search per finished move.

opw-4882390

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

Forward-Port-Of: odoo/odoo#283952
Forward-Port-Of: odoo/odoo#283234