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

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

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#116124
Forward-Port-Of: odoo/enterprise#115065

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

When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots.

Steps to reproduce:
-------------------
* Create a product with Tracking by lots
* In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)"
* Create a quotation with the product and confirm it
* Validate the delivery
* In POS, settle the sale order from Quotation/Order
* When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes

> Observation:
Quantity doubled.

Why the fix:
------------
read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice.
We now use move lines from exactly one picking and filter by sale_line_id.

opw-6001585

Forward-Port-Of: odoo/odoo#262237
Forward-Port-Of: odoo/odoo#253539

### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#259005
Forward-Port-Of: odoo/odoo#253406

When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots.

Steps to reproduce:
-------------------
* Create a product with Tracking by lots
* In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)"
* Create a quotation with the product and confirm it
* Validate the delivery
* In POS, settle the sale order from Quotation/Order
* When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes

> Observation:
Quantity doubled.

Why the fix:
------------
read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice.
We now use move lines from exactly one picking and filter by sale_line_id.

opw-6001585

Forward-Port-Of: odoo/odoo#262237
Forward-Port-Of: odoo/odoo#253539

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#239369
Forward-Port-Of: odoo/odoo#229275

# How to reproduce
- Create a Product with more than 256 variants
- Publish it to the website
- Go to the website and add a Product Carousel
- Set it to display newest products & hide variants

# The problem
Fewer than 16 products are displayed

# Cause
This issue was already adressed by this commit :
https://github.com/odoo/odoo/pull/195857

But because of limitations for specifically the "Newest Products" filter (cf. original commit message), the fix was only a workaround. Indeed, it increased the search limit to 256 before filtering out the variants, which caused problems when there was more than 256 variants.

But since then, big changes made in 19.0 has allowed us to implement a better fix : https://github.com/odoo/odoo/commit/e3b062e5d3820

# Proposed Solution
Since we can now pass the model in the options :
https://github.com/odoo/odoo/blob/b5069328734e623c12b0de50a177d501f7f0c995/addons/website/models/website_snippet_filter.py#L90

We give "product.template" when the `hide_variants` option is enabled and we filter on products. This allows use to remove the whole workaround that needed increase the limit on product searchs then getting their templates.

A recent commit blocks passing "product.template" since it does not have a dedicated snippet filter : https://github.com/odoo/odoo/pull/257208/changes/8e264ae4ea6ae16bbd410ac384733ff8759938a6

But in the commit message, they mention that this targets snippet in single-record mode, which is not our case. So, we move the logic to only be applied for single-record filters

opw-6054059

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

Forward-Port-Of: odoo/odoo#260340

Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#115100

### Issue:
With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier
This makes no sense for internal moves

### Cause:
The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id`
However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed

### Steps to reproduce:
- Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company
- In Settings, enable `Multi-Step Routes`
- Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)`
- Create a Product (e.g. RO product)
- Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product)
- Create and Confirm a Sale Order for the RO Product
- From the Sale Order, click Delivery and validate the picking 
### Before the fix, internal transfers raised:
`The picking RO Co/PICK/00001 is missing a delivery carrier.`

enterprise-PR: https://github.com/odoo/enterprise/pull/114166
opw-5925087

Forward-Port-Of: odoo/odoo#257293

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/odoo#259678
Forward-Port-Of: odoo/odoo#257258

Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription

Steps to reproduce:
1. Install Subscriptions
2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago
3. Confirm the subscription
4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token"
5. Go back to the previously created subscription (see that a reminder email has been added in the chatter)
6. Duplicate the subscription and confirm the duplicate
7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again
8. There are no reminder for the duplicate subscription

Issue:
The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here
https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120

Solution:
Set `copy=False` on the field `last_reminder_date`

opw-6167356

Forward-Port-Of: odoo/enterprise#115509

Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription

Steps to reproduce:
1. Install Subscriptions
2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago
3. Confirm the subscription
4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token"
5. Go back to the previously created subscription (see that a reminder email has been added in the chatter)
6. Duplicate the subscription and confirm the duplicate
7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again
8. There are no reminder for the duplicate subscription

Issue:
The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here
https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120

Solution:
Set `copy=False` on the field `last_reminder_date`

opw-6167356

Forward-Port-Of: odoo/enterprise#115509

Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#115100

The Confirmation mailing template ships an `s_text_block` section without `data-vxml`. The mass_mailing builder compares it against the canonical snippet's `data-vxml="001"` and flags the block as outdated. Clicking ACCESS OPTIONS ANYWAY in the sidebar leaves the section flagged but saves an empty `body_html`, so the confirmation test email arrives blank.

https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/mass_mailing/static/src/builder/plugins/version_control_plugin.js#L23

The section is structurally identical to the canonical snippet and to the version already used by the default theme template, so adding `data-vxml="001"` makes the version check match and the outdated banner is no longer shown.

https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/mass_mailing/views/snippets/mass_mailing_text_snippets.xml#L3

https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/mass_mailing/views/themes_templates.xml#L41

Steps to reproduce:
1. Marketing Automation > New > Marketing > Double Opt-in > Create Campaign
2. Open the Templates smart button and click the Confirmation row
3. Click the welcome block in the email body
4. Click ACCESS OPTIONS ANYWAY in the right sidebar
5. Click Test and send to your address

=> arriving email body is empty

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6143321)
opw-6143321

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

When both `accountant` and `knowledge` are installed, the `accountant_knowledge` module is automatically added and extends the `knowledge.article` model. It introduces a link from articles to audit reports via the `audit_report_id` field (see: `audit_report_id` field).

Currently, only users in the `account.group_account_user` group have full CRUD access to audit reports. Users outside this group may encounter access errors when loading an article or a template. This happens because the ORM attempts to read the `audit_report_id` field, but fails due to insufficient permissions on the related model.

To resolve this, new access rules and record rules will be introduced on the `audit.report` model so that its permissions are derived from the linked article. The user should then no longer get an access error when loading the `audit_report_id` field from an article or a template.

Thanks to these new security rules, audit reports that users cannot access will be hidden from the interface. This improves the overall user experience and prevents errors, such as crashes when attempting to open the article linked to the audit report.

opw-6067390

Issue
-----
Putting a max weight on a package type causes getting a rate with Sendcloud to fail.

Steps to reproduce
-----
- Setup Mondial Relay using Sendcloud
- Set a default package type with max weight 2kg
- Create a product with a 500g weight
- Create a SO with the product
- Add delivery
	- Sendcloud Mondial Relay
	- Get rate

> Impossible to get a rate

Cause
-----
When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order.

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81

However, when making the rate call, we use the value returned by `_split_shipping`

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91

which is equal to the maximum weight of the package. This is blocking in some cases, like if
- the real weight is 750g
- the package max is 2kg
- Sendcloud returns a shipping method for [500g;1kg]

Asking a rate for this method & a 2kg package will fail (rightfully so).

Solution
-----
The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one.

Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight.

-----
Ticket:
opw-5947199

last week this fix deployed https://github.com/odoo/enterprise/pull/112652

https://www.postgresql.org/docs/14/sql-copy.html
in older version posgress like 14.0 ``Header`` is only accepting [boolean] parameter.

```
Traceback (most recent call last):
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/registry.py", line 110, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/loading.py", line 481, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/loading.py", line 366, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/loading.py", line 234, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/migration.py", line 216, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
  File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/migration.py", line 240, in exec_script
    migrate(cr, installed_version)
  File "/tmp/tmpfiag6d7a/enterprise/17.0/product_unspsc/upgrades/0.3/post-update-codes.py", line 16, in migrate
    cr.copy_expert("COPY _upgrade_product_unspsc_code FROM STDIN WITH (DELIMITER '|', HEADER MATCH)", csv_file)
psycopg2.errors.SyntaxError: header requires a Boolean value
```
detected here
https://upgradeci.odoo.com/upgradeci/run/294631