Version:
---------
- 19.0+

Steps to reproduce:
--------------------

1.Install modules `sale_management`, `purchase`, and `mrp`.
2. Go to Settings and enable the MTO (Replenish on Order) route.
3. Create a product with:

       i. Configure a Vendor under the Purchase tab.
      ii. Set the route to MTO.
     iii. Create a Bill of Materials for the product.
5. Create a Sale Order with the configured product and confirm it.
6. Open the generated Manufacturing Order.
7. Duplicate the Manufacturing Order.

Issue:
------

* The duplicated Manufacturing Order shows a smart button
linked with the Sale Order, which is incorrect.

Root Cause:
------------
 This issue is coming form this [Commit](https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a#diff-2b9de2e50ff5e1dc0362b825bac2b07623770fb3275b3257ef972f255f3ccb8b) 

* During Sale Order confirmation, the flow
`action_confirm` → `_action_confirm` → `_action_launch_stock_rule`
→ `run` → `_run_pull` → `_action_confirm` calls
`_prepare_procurement_values`.
which gather all procurement values.
In sale_stock, the super call adds `sale_line_id` to the
generated Manufacturing Order when using MTO:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/sale_stock/models/stock.py#L138-L140

* So, when the Sale Order is confirmed, the generated
Manufacturing Order contains sale_line_id, and when this
Manufacturing Order is duplicated, the sale_line_id is also
copied.

* In sale_mrp, the smart button uses sale_line_id to compute
the linked Sale Order count:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/sale_mrp/models/mrp_production.py#L19

Solution:
-----------
* Prevent copying of sale_line_id when duplicating a
Manufacturing Order, ensuring duplicated records are not
linked to any Sale Order.

---

opw-6113149


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

Forward-Port-Of: odoo/odoo#259128

Currently, an error will occur when user puts Date of Salary Increase in the past on the salary increase wizard.

Steps to replicate:
- Install `hr_payroll` and create a new employee.
- From the cog menu click `Salary Increase`.
- Put any date from the past in the `Date of Salary Increase` field.

Error:
```py
File '/home/odoo/src/enterprise/saas-19.3/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py', line 43, in _get_affected_version_ids
    increase_base_version = employee.version_ids.filtered_domain([('date_version', '<=', self.increase_date)])[-1]
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 6135, in __getitem__
    ids = (self._ids[key],)
IndexError: tuple index out of range
```

Cause:
- When the user changes the salary increase date, it triggers the [compute], which calls `_get_affected_version_ids()`. In this method, employee versions [1] are filtered to keep only those whose `date_version` is less than or equal to the selected increase date.

- For newly created employees, version_ids typically contain only an initial version with date_version set to today's date. Therefore, when the selected salary increase date is earlier than today, the filter returns an empty recordset, which later causes the crash when accessing the last record of that recordset.

Solution:
- Early returned empty recordsets when no matching employee versions are found for the selected increase date.

[compute]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L34-L39

[1]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L43

sentry-7498213478

Steps to reproduce:
1.Open the website in Edit mode.
2.Add a snippet with an image.
3.Replace the image.
4.After replacing image, double-click on it to open the Media Dialog.
5.Inside the Media Dialog, double-click on the same or any other image.
6.Traceback occurs.

Before this commit:
parentElement was becoming null because parentElement is a DOM
position check.it requires the element to be physically attached in
the DOM tree to find its parent.Since this.props.node is not yet in
the DOM at that point, parentElement returns null.

After this commit:
1.The issue is fixed using a boolean flag: isProcessingClick. Initially,
the flag is set to false. When the first click starts, it is updated to
true. If another click occurs during the same flow
(e.g during a double click), isProcessingClick is already true, so the
function immediately returns and prevents the action from being executed
multiple times.
2.we now pass closestSnippetEl directly from replaceMedia() through
params.this allows the dialog taken snippet reference using
(closestElement(mediaEl , "[data-snippet]")) without depending on the
media node being attached to the DOM.

task-6033320

Forward-Port-Of: odoo/odoo#266664
Forward-Port-Of: odoo/odoo#254790

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606

Forward-Port-Of: odoo/odoo#266509
Forward-Port-Of: odoo/odoo#259370

**Description of the issue/feature this PR addresses:**
This PR fixes an "Invalid Operation" UserError during the Bill Matching process. The error occurs when Odoo attempts to call the line addition method on a Posted Vendor Bill, even when there are no new residual lines to add. This triggers a write attempt on read-only fields (such as invoice_line_ids) of a validated account move, which is prohibited by Odoo’s ORM.

Furthermore, this addresses a functional inconsistency: Odoo allows users to select "Posted" bills in the matching view, but the underlying code is not prepared to handle a "zero residual" scenario on a validated move. If Odoo intends to prevent matching on posted bills, they should be filtered out from the view; since they are available to select, the system must be able to process them when no further modifications to the accounting entries are required.

**Current behavior before PR:**
When performing a match between a posted Vendor Bill and Purchase Order lines where the "residual" (lines left to add) is zero:

The system executes _add_purchase_order_lines() regardless of whether the recordset of lines is empty.
Odoo's ORM detects an update attempt on a posted record.
A UserError is raised: "You cannot modify the following readonly fields on a posted move: invoice_line_ids".
This blocks the user from completing the matching process even if the lines are already technically accounted for.

**Desired behavior after PR is merged:**
The system will check if residual_purchase_order_lines contains any records before attempting to update the bill.
If there are no lines to add, the method call is skipped.
The matching process completes successfully without attempting an illegal write on a posted move.

**Steps to Reproduce**
1) Create a Purchase Order (PO): Add a product (e.g., "Acoustic Bloc Screens") and confirm the order.
2) Create a Vendor Bill manually: Do not use the "Create Bill" button from the PO. Instead, go to Accounting -> Vendors -> Bills and create a new bill for the same vendor and product.
3) Post the Bill: Set a bill date and click Confirm to move it to the "Posted" state.
4) Open Bill Matching: Go back to the Purchase Order and click the Bill Matching button (or navigate to the matching view).
5) Select Lines: Select the PO line and the corresponding Bill line (which are already equal in quantity/price).
6) Trigger the Match: Click on the Match button.

Observe Error: An "Invalid Operation" popup appears, preventing the link because Odoo tries to "add" zero lines to a posted invoice.


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

Forward-Port-Of: odoo/odoo#241171

Steps to reproduce:
- Install `Accounting` module
- Search `Analytic Report` > Click on `Total` > `Custom Group`
- Select `Journal Item` > Now again close and select `Journal Item`

Traceback:
```js
TypeError: Cannot destructure property 'fieldName' of 'searchItems.find(...)' as it is undefined.
    at AnalyticPivotRenderer.onGroupBySelected (http://localhost:8069/web/assets/3b7bf10/web.assets_backend_lazy_dark.min.js:434:7)
    at Object.onSelected (eval at compile (http://localhost:8069/web/assets/b0799bf/web.assets_web.min.js:1376:421), <anonymous>:78:62)
    at DropdownItem.onClick (http://localhost:8069/web/assets/b0799bf/web.assets_web.min.js:2373:24)
 ```

Cause:
Custom groupBys were not being added to the search items list in `onGroupBySelected`, causing a lookup failure when selecting a custom groupBy from the dropdown.

Solution:
Added custom groupBys to the search items list so they can be found and applied correctly.

opw-6227164

Forward-Port-Of: odoo/odoo#265810

**Issue:**
The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'.
This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification.

**Steps to reproduce:**
- Setup a 'sepa_ct' payment method on a bank journal.
- Create a bill with a vendor with a trusted bank account.
- Create a payment for that bill with a 'sepa_ct' payment method.
- Add the payment to a batch.
- Manually set the `payment_online_status` = 'pending'.
- Create a bank transaction and reconcile it with the batch.
- Try to unreconcile the lines on the transaction
- Result: UserError 'You cannot modify a payment that has already been sent to the bank.'

**Fix:**
Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow.

OPW-6080464

Forward-Port-Of: odoo/enterprise#118342
Forward-Port-Of: odoo/enterprise#117921

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117318
Forward-Port-Of: odoo/enterprise#115046

**Steps to reproduce**
1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`.
2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the invoice.
3. Generate the FA(3) XML.

**Issue**
`P_6` is omitted from the payload even though the delivery date differs from the invoice issue date.

The FA(3) information sheet (Warsaw, September 2025, binding from 1 February 2026) defines `P_6` as *"the date of delivery [...] if such date is specified and differs from the date of issue of the invoice"*, where the date of issue is `P_1` (Art. 106e sec. 1 item 1 of the VAT Act). In Odoo `P_1` maps to `invoice_date`, but the template at
https://github.com/odoo/odoo/blob/4890b8021af2a5c025944220043d295bb7bbbb9b/addons/l10n_pl_edi/data/fa3_template.xml#L132 compares `delivery_date` against `invoice.date`, the accounting/entry date. When the invoice is posted on the delivery day the accounting date equals the delivery date, the guard evaluates to false, and `P_6` is wrongly dropped.

Comparing against `invoice.invoice_date` aligns the guard with `P_1` as the spec requires.

Ticket [link](https://www.odoo.com/odoo/project.task/6211119)
opw-6211119

Forward-Port-Of: odoo/odoo#266667

### Issue:
When creating a company with CUIT 30999003156, any child contact added under it is incorrectly considered as a company

### Cause:
In `l10n_ar`, `_compute_is_company()` relies on:
`l10n_ar_afip_code` and the prefix of `l10n_ar_vat`

However, these fields are propagated to child contacts
As a result, child contacts inherit the same values as the parent company and are incorrectly computed with `is_company = True`

### Note:
This same fix also fix the issue on `l10n_latam_base` and `l10n_co`

### Steps to reproduce:
- Install `l10n_ar` and switch to an AR Company
- Create a Partner in Contacts (Name: Test Company, Country: Argentina, Identification Number: CUIT 30999003156)
- Add a Contact (Name: Test Contact)
- Go in Contacts and add a Filter for Name: Test

### Before the fix:
The Contacts are: Test Company and Test Contact

### After the fix:
The Contacts are: Test Company and Test Company, Test Contact

opw-6140921

Forward-Port-Of: odoo/odoo#263503

**Steps to reproduce:**
- Install the `l10n_fr_account_loans` module and switch to a `FR Company`.
- Navigate to Accounting > Accounting > Assets & Liabilities > Loans.
- Create a new loan record.
- Click `Add a line`, set a `Date`, and `save` the record.
- Click `Add a line` again.

**Error:**
`TypeError: '>' not supported between instances of 'datetime.date' and 'bool'`

**Root Cause:**
At [1], when adding a line after the record has already been saved with 
at least one existing line, the existing line has a valid `datetime.date` 
value for `l.date`, while the newly created unsaved line still has `line.date` 
set to `False`. This results in a comparison between a `datetime.date` object 
and a boolean value, causing an error.

**Fix:**
This commit prevents the errors when adding multiple lines after saving the 
record by applying a fix similar to [2].

[1]:
https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/l10n_fr_account_loans/models/account_loan_line.py#L21

[2]:
https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/account_loans/models/account_loan_line.py#L61-L63

opw-6244973

Forward-Port-Of: odoo/enterprise#118354

**Issue**
The scrap location provided by the user may be overridden while confirming a scrap move

**Steps to reproduce**
- In settings, enable the tracking of location in the warehouse
- Have two location of type 'Inventory loss'
- Create a scrap move and change the scrap location
- confirm the move
-> The scrapped move will be created using the scrap location already present before the user changes it

**Cause**
The regression has been introduce by this refactoring commit: https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba

While confirming the scrap move:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L2726
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L2731
It needs to access the `stock.move` record:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L2133
Since this is the first access, it triggers the compute method of `location_dest_id`:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L227-L228
Which sets it to the company's scrap location, regardless of the value provided by the user:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L237-L238
This value is compute here:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/res_company.py#L62-L65
This value is computed by taking the first scrap location found for this company

opw-6125152

Forward-Port-Of: odoo/odoo#261803

Issue:
After installing the US chart of accounts, a few accounts still receive numeric codes on new 19.3 SaaS databases, for example: Bank Suspense Account (1014) Bank journal default account (1015)
Outstanding Receipts (1016)
Funds in Transit (1017)
Outstanding Payments (1018)

The rest of the chart has no codes, as intended.

Steps to reproduce:
1) Create a clean database on 19.3
2) Install accounting with United States localization (l10n_us / l10n_us_account) 3) accounting > configuration > fiscal position set to US 4) Open Accounting > Chart of Accounts 5) Observe that some bank accounts (and the Bank journal account) have codes 1014–1018 while other accounts have no code

Cause:
this commit https://github.com/odoo/odoo/pull/253759/changes/45d29f576baea0f92552af04229e1049037f8271 removed US account codes from the US CSV and set `code_digits` to 0: https://github.com/odoo/odoo/blob/73252cd9bfaa07ea004f7ac82a68afa558c09e9c/addons/l10n_us_account/models/template_us.py#L9-L13

Those accounts are not in the US CSV, Core account still creates them using company bank/cash/transfer prefixes, so they were the only ones that kept getting codes, because `code_digits` is 0, `len(prefix) < 0` is always false, so the code becomes the prefix itself (1014, 1015, 1017, ...) https://github.com/odoo/odoo/blob/73252cd9bfaa07ea004f7ac82a68afa558c09e9c/addons/account/models/account_account.py#L1059

Solution:
- Set `bank_account_code_prefix`, `cash_account_code_prefix`, and `transfer_account_code_prefix` to `False` in the US chart template company data so those auto created accounts get no prefix and no generated code.

opw-6211806

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

The CTE `model_fees` is supposed to get the reconciliation models that match conditions that involves a join with the ir.model.data table. One of these conditions is filtering based on the `name` field with an `LIKE` operator.

On databases that has a GIST index on the field `name`, the planner will prefer to filter the records based using the GIST index and add the extra filters as a filtering criteria after the index condition if the index-condition wasn't possible to be switched to a range-query. The condition is supposed to be a prefix-matching, which can be evaluated directly by a B-TREE if the field had an index and the planner can convert the condition to a range-query.

Apparently the `_` in `account_reco_models_fees_%%` was evaluated as a wild-card, making the condition a substring-matching rather than direct prefix-matching. In this PR, I have modified the condition to escape the '_' wildcards.

The benchmark done below was on a database that has around **10^7** `ir.model.data` records and 1K `account.reconciliation.model` records. I have split the benchmark into two cases, a case where the buffer-pool of
postgres warmed-up and a case where it is not.

After Worst case -> https://explain.dalibo.com/plan/975geg1f1h109d5c
Before Worst case -> https://explain.dalibo.com/plan/0ce9bf3g0ad8f98b

After Best Case -> https://explain.dalibo.com/plan/1a77459dadb0gfc4

Definition of ir_model_data_name_idx2  -> CREATE INDEX ir_model_data_name_idx2 ON public.ir_model_data USING gist (name gist_trgm_ops)

Definition of ir_model_data_module_name_uniq_index -> CREATE UNIQUE INDEX ir_model_data_module_name_uniq_index ON public.ir_model_data USING btree (module, name)


| PostgreSQL Buffer Pool Status | Before | After |
| :--- | :--- | :--- |
| Not warmed up (Cold) | 11s | 130ms |
| Warmed up (Hot) | 0.022ms | 0.097ms |

Forward-Port-Of: odoo/enterprise#117746

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

*: html_editor, html_builder

### Commit 1:
[FIX] html_editor, website: improve helper util setSelection and tests
**Before this commit**: after the selection restriction commit (https://github.com/odoo/odoo/commit/d09c8fd428315b8c3bf08c43d55da50fcd77f2ae),
the tests have to dispatch events specifically to mimic the selection
made by mouse.

**After this commit:** we improve the setSelection helper to include a flag
isMouseEventSimulated and simplify the tests.

task-6143995


### Commit 2:
[FIX] html_builder*: improve selection correction for nested uncrossable
*: website

**Before this commit:** correctSelectionOnUncrossable is not exhaustive for
complex html snippets. When there are multiple uncrossable elements in
the selection, and there's a parent uncrossable element including other
uncrossable ones, the selection is only restricted on the parent
uncrossable element.

We had a fix for the select all behavior but not for mouse selection.
Reproduction:
- Have a blockquote snippet with some text around it
- Select the text from the blockquote to the text after it => it will
keep the authors info selected
- And then, if I click on the text, the selection will restrict to the
text without the author infos

**After this commit:** We now always correct the selection on uncrossable in
an iterative way, until the selection is not corrected anymore or a
maximum of attempts is reached.

We didn't use the loop condition like previously done. Because there can
still be an uncrossable inside the selection, when the closest
uncrossable elements of the focus node and anchor node are the same.
Instead, we stop the looping when the selection isn't being corrected
anymore.

task-6143995



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