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

**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

### Issue before this commit:
Opening the Purchase Matching wizard would crash if the vendor bill contained lines with a description and a Unit of Measure (UoM), but no product selected.

### Steps to reproduce the issue:
1. Enable Units of Measure in Settings
2. Create and confirm a Vendor Bill setting a description and a UoM, but leave the Product field empty.
3. Click on "Purchase matching" smart button
4. The system throws a traceback with the error: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure False defined on the product."

### Cause of the issue:
In the purchase.bill.line.match model, the field product_uom_qty was computed by calling _compute_quantity using line.product_uom_id. Since product_uom_id is a related field on product_id.uom_id, it returns False when no product is set. The UoM conversion logic cannot handle a False destination category, leading to the crash.

### Reason to introduce the fix:
Make purchase matching robust when imported vendor bills contain lines identified only by their description and not by a product. Note that for `purchase.bill.line.match` corresponding to an account.move.line but not related to any product, the `product_uom_qty` should match the quantity of the `aml_id` instead of attempting a UoM conversion based on a missing 
product UoM for the behavior to be consistent with the inverse method:

https://github.com/odoo/odoo/blob/59d6232979b8499fde6cb700df1870e2e38d0d3e/addons/purchase/models/purchase_bill_line_match.py#L45-L54

opw-5911526

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

Forward-Port-Of: odoo/odoo#266269
Forward-Port-Of: odoo/odoo#257827

Step to reproduce:
- install point_of_sale with demo
- have two company and 1 pos in each company
- install pos_hr
- install pos_sale

Observation:
- we get a traceback
```
File "/src/saas-19.2/odoo/orm/fields_misc.py", line 115, in __get__
    raise ValueError("Expected singleton: %s" % record) from None
ValueError: Expected singleton: res.company(7, 8)
 ```
- and pos_sale is not installed

Cause:
- when installing `pos_sale`  `_ensure_downpayment_product` is called.
- this sets downpayment product on every `pos.config` record.
- this triggers write call from pos_hr, which tries to identify users for pos
- this uses `with_company(self.company)`   <-----  actual issue
- here self has two config, each from different company, hence `with_company`
raises singleton error

why not in earlier verison:
- before commit [1] we only set downpayment product on only pos_config_main
- now we set it on every pos.config, so now self contain multiple records

[1] https://github.com/odoo/odoo/commit/a3f9114434c7cab8757b0283698662792e6b7946

Fix:
- compute users by first grouping them over company_id
related pr: https://github.com/odoo/odoo/pull/254026


opw-6217135

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

Issue:
----------------------------------------
The default values aren't kept when using the previous/next arrows in planning calendar view.

Steps to reproduce:
----------------------------------------
- Go on a Project task
- Click the "To Schedule" button
- Switch to calendar view
- If we create now, the new slot will have the task as default value
- Click the arrow to switch to next week
- If we create there will be no default values

Cause:
----------------------------------------
Since 7b844902e5c3a7aeedda6cc2be61366caad2d144 the context is lost when using the arrows.

When switching to calendar view `load()` is called with the context in the params:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/model/model.js#L163-L164

But when using the arrows, it is called with only a date:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/views/calendar/calendar_controller.js#L426

So `...params.context,` is empty, and the context is only `hide_planned_dates: true,`.

Solution:
----------------------------------------
If no context is specified in params, we use the one in `this.meta` to allow changing the context by giving it in the params but keeping the previous context when it's not given.

opw-6211055

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

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

Forward-Port-Of: odoo/odoo#264435
Forward-Port-Of: odoo/odoo#259384

*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.

**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
  - Operation type: Receipts
  - Control per Quantity
- Create a PO for the final product:
  - With a quantity of 3
  - With the associated partner be the one mentioned in the subcontracting BOM
  - Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product

-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available

**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94

When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471

This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320

As a result, the reduction could be applied to a production unrelated to the inspected lot.

**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.

opw-5427873

Forward-Port-Of: odoo/enterprise#104424