**Steps to reproduce**
- Settings: Timesheets > Invoicing policy = only validated TS.
- Have a service product with an invoicing policy based on timesheets.
- Create a sales order using this product.
- From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them.
- Invoice the SO, using a timesheets period that includes both TS.
- Notice that the quantity of the invoice line includes the non-validated timesheet.

**Cause**
The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1

**Change**
Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain.

opw-6116670

Forward-Port-Of: odoo/odoo#262350
Forward-Port-Of: odoo/odoo#259224

**Steps to produce:**
- Install `sale_management` without demo data.
- In settings > Under Taxes > Set `Tax Prices` as `Tax Included`.
- Create a product with a sales price of 10.
- Create a quotation with this product.
- Confirm the line amount shows 10 (tax included).
- Click on preview.

**Observation:**
- In the preview, the product line amount is shown as tax excluded.

**Root cause:**
- At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`.
- This logic is not applied in the portal preview and PDF report.

**Solution:**
- Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`.

[1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663

Before:
---
<img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" />

After:
---
<img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" />

opw-6089473
---

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

Forward-Port-Of: odoo/odoo#261892
Forward-Port-Of: odoo/odoo#258551

### Steps to reproduce:

- Create and confirm an MO for 1 unit of product without bom
- Set the producing quantity to 1
- Add a new component line for a product tracked by SN
- Click on details operation and add a lot > Save
- Produce all
#### > The quantity is of the component move is reset to 0 and the lot erased

### Cause of the issue:

Setting the producing quantity to 1 will set the state of the of the MO to `to_close`. After which, adding a new move will add it in the appropriate `picked` state so that the move is considered when validating the MO:
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/mrp/models/stock_move.py#L269-L270 
However, clicking on the detailed operation and selecting a lot will create a new `move_line` without set `picked`. As such the related picked compute method of the stock move will be launched:
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L123-L127
resetting the picked state of the move to False as a new move line was added (triggering a dependency of its compute method):
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L126
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move.py#L280-L286

Additional change:

The test `TestSubcontractingBasic.test_flow_tracked_1` underlined that the `auto_pick_move_lines` context key added to `action_show_details` had to be cleaned in subcontracting flows before synchronizing the subcontracted productions:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/mrp_subcontracting/models/stock_move_line.py#L34-L38
Otherwised, if a receipt for tracked subcontracted product is picked and additional move lines are added via the detailed operations, the subcontracted backorders created to fulfill the additional demand will will pick each of their move leading to subcontracted MO's that will avoid assignment:
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L1914-L1916
and be cancelled at the picking validation:
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/mrp/models/mrp_production.py#L1924
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L2107-L2109
This can be checked by launching the test without the `clean_context`.

We also improve the `TestSubcontractingBasic.test_flow_tracked_1` test as it is not possible to edit moves to be picked prior to confirmation and since move lines can not manually be created in picked state.

### Fix:

Note that we rely on a context key to adapt the compute method of the picked field of the `stock.move.line` instead of adding a `default_picked` context in the `action_show_details` because the new move lines added to the list view of the `move` form are generated via the UI by opening a list of `stock.quant` which cleans the `default_context` key prior to generation of the `new` move line. In particular, the exact UI flow can not be tested by relying on the `Form` class of stock moves since the new move lines will then be created by via the `O2MForm` class:
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L642-L658
and an onchange of the stock move line will be triggered to determine its value relying on the `default_picked` context key to create the new move line in picked state:
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L332-L339
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L579
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/addons/web/models/models.py#L2005-L2008
By contrast performing the flow from the interface will highlight that the `default_picked` context key does not solve the issue.

opw-5991985

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

Forward-Port-Of: odoo/odoo#258935

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359

Forward-Port-Of: odoo/enterprise#115899
Forward-Port-Of: odoo/enterprise#114473

Steps to reproduce
1. Install l10n_ar (or any LATAM localization).
2. Go to Accounting > Configuration > Journals and open a Purchase journal
   that has "Use Documents?" enabled.
3. Enable "Secure Posted Entries with Hash".
4. Create and post a vendor bill with a high document number (e.g. 00001-00009999).
5. Create another vendor bill with a lower document number (e.g. 00001-00000100)
   and try to post it.

Issue
Posting the second vendor bill fails with:
"This move could not be locked either because some move with the same sequence
prefix has a higher number. You may need to resequence it."

The hashing logic in account_journal.py enforces a strict continuous sequential
chain per journal:
https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678

In LATAM countries, vendor bill document numbers are assigned by the vendor, not
by Odoo. A bill with a lower number can legitimately be entered after one with a
higher number, which breaks the sequential assumption the hash chain relies on.
Allowing it would produce a hash that no longer represents a proper chain, giving
users a false sense of security. Sales journals are unaffected because Odoo
controls their sequence.

Solution
Hide the "Secure Posted Entries with Hash" field on purchase journals that have
"Use Documents?" enabled, preventing users from enabling an option that cannot
work correctly for vendor-assigned document numbers. Sales journals keep the
option available since Odoo controls their sequence.

opw-6076673

Forward-Port-Of: odoo/odoo#262614
Forward-Port-Of: odoo/odoo#259206

When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.

When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.

Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.

In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.

#### speedup

In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.

In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.

opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753

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

Forward-Port-Of: odoo/odoo#240860
Forward-Port-Of: odoo/odoo#229275

**Steps to reproduce:**
- Order a combo in the self order Mobile with multiple products
- Order the same combo more than once
- Checkout and go to the linked restaurant
- Go to the orders, the price is not the same as in the self
- If you check the unit prices in the backend, they are not consistent

**Why the fix:**

This is mostly a backport of bd117e8 with an addition because the extras still did not work as intended.

In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines.

This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 
But the total price has been computed to zero, so the previously computed price_unit is overridden and set to zero.

We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line.

The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation.

There was an oversight in the original fix, which meant that the unit prices were not distributed as they should have been, even though the total was correct. When we only order one combo that costs 25 and has 2 items, both items will have a price_unit of 12.5, but if we have more than 1 qty of said combo, the price_unit will be all over the place and the second item will have to compensate for the first one thanks to
https://github.com/odoo/odoo/blob/b108bb847b1c4d3a91f223d77a4888b8139b0a8d/addons/pos_self_order/models/pos_order.py#L322-L323

We now update the original total to take the fact that multiple combo can be ordered.

opw-6076911

Forward-Port-Of: odoo/odoo#261810
Forward-Port-Of: odoo/odoo#257922

**Description**

With odoo/odoo#247578, we were storing static column names in the list
definition during migration and list insertion. As a result, list header
labels stopped being translatable.

This was originally done because spreadsheet pivots created from list
ranges can break when translated headers change from one language to
another.

In this commit:
- make `string` optional in list column definitions so headers fall back
  to the translated field display name when no explicit label is stored
- keep explicit/custom labels by storing `string` only when a stable
  header is really needed
- update list migration, insertion, and reinsertion flows so they no
  longer force static labels by default
- simplify the list side panel so users can choose between the automatic
  translated label and a custom stored label
- when creating a spreadsheet pivot from a list range in multi-language
  mode, automatically store the current displayed labels only for the
  list columns used by that pivot so the pivot stays stable across
  languages

Task: 247578

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

**Description**

With odoo/odoo#247578, we were storing static column names in the list
definition during migration and list insertion. As a result, list header
labels stopped being translatable.

This was originally done because spreadsheet pivots created from list
ranges can break when translated headers change from one language to
another.

In this commit:
- make `string` optional in list column definitions so headers fall back
  to the translated field display name when no explicit label is stored
- keep explicit/custom labels by storing `string` only when a stable
  header is really needed
- update list migration, insertion, and reinsertion flows so they no
  longer force static labels by default
- simplify the list side panel so users can choose between the automatic
  translated label and a custom stored label
- when creating a spreadsheet pivot from a list range in multi-language
  mode, automatically store the current displayed labels only for the
  list columns used by that pivot so the pivot stays stable across
  languages

Task: 247578

## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**

## Cause
The condition to raise the error message does not take into account the state of the leave:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204

This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.

(related to)
opw-6089990

Forward-Port-Of: odoo/enterprise#116024
Forward-Port-Of: odoo/enterprise#115765

Steps to reproduce:
- Install documents_account and account_accountant.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
When attaching an image via a log note, the file becomes the main
attachment but is intentionally unlinked (res_model=False) by the
system to avoid UI clutter. Downstream modules unknowingly sync this
orphaned file. Later, when "Send & Print" generates the real PDF,
the system attempts to update the orphaned downstream record, causing
model linkage conflicts and eventually a crash.

Solution:
Add `no_document=True` to the context during `_message_post_after_hook`
for invoices. Previously, for incoming emails or log notes, the mail
framework would trigger document creation immediately before the core
accounting module could evaluate and orphan invalid files (like images).
This change suppresses that premature sync, allowing downstream modules
to explicitly handle the sync after the attachment's final state is
resolved.

opw-5930888

Forward-Port-Of: odoo/odoo#262637
Forward-Port-Of: odoo/odoo#258307

Steps to reproduce:
- Set a journal with documents folder sync.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
Adding an image via log note sets it as the main attachment, but it 
is intentionally orphaned (res_model=False) to prevent UI clutter. 
`documents_account` incorrectly syncs this unlinked file, creating a 
workspace document with a missing model.

During "Send & Print", the official invoice PDF replaces the image as
the main attachment. The document versioning logic intercepts this swap
and attempts to re-parent the new PDF to match the orphaned document.
This destroys the PDF's linkage to the invoice, causing a crash when
the system later attempts to fetch the PDF.

Solution:
Since the base module now suppresses premature document creation during 
the message post, we explicitly handle the sync ourselves. We override 
`_fix_attachments_on_record_from_files_data` to iterate over the 
validated attachments and trigger document creation only for files 
that retained their `res_model`. We also add a check inside 
`_update_or_create_document` to strictly block orphaned attachments.

opw-5930888

Forward-Port-Of: odoo/enterprise#116247
Forward-Port-Of: odoo/enterprise#115065