**Issue:**
The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion checking :
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/odoo/orm/models.py#L5207


This assertion is failing because of the condition related to `is_dropship`. When `is_dropship` is `True`, the `partner_id` is expected to be `p.sale_id.partner_shipping_id.id`
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95
However, for the specific picking record in some cases, `sale_id` is not set
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/sale_stock/models/stock.py#L190
As a result of the current implementation, the [expression](https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95) evaluates to **False**. That False value is then included in the generated list.
**For example** : lot.partner_ids = [2, False, 5, 6]
With the recent changes, when this assignment happens, it **no longer ignores False values**. Instead, during the write process, the ORM internally calls **browse()** on the provided IDs. Since False is not a valid ID, the assertion inside browse() **fails**, this can be seen in the **traceback**.

This shows that when the field is being written, the ORM validates the IDs by calling browse(), and since False is included in the list, the assertion fails.

**Solution:**
To resolve this issue, I have use `mapped. As 'mapped()' will filter out all the empty(False) values from the recordset.

By switching to **mapped()** and returning a recordset instead of a list of IDs, False values are automatically excluded. As a result, no invalid IDs are passed to browse(), and the assertion error is avoided.

I have also added the if `p.is_dropship and p.sale_id.partner_shipping_id` condition because it fallback to the picking partner if there is no sale order partner to use

**Other Optimization:**
I have used `with_prefetch` to fetching `picking_ids`, it is just the purely ORM friendly optimization.
It ensures that all related records are prefetched efficiently across lots. It is not related to the bug above mentioned.

**Traceback:**
```python

   File "/home/odoo/src/odoo/saas-19.1/addons/stock_dropshipping/models/stock.py", line 95, in _compute_partner_ids
    lot.partner_ids = list(p.sale_id.partner_shipping_id.id if p.is_dropship else p.partner_id.id for p in picking_ids)
    ^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1866, in __set__
    self.write(protected_records, value)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 765, in write
    self.write_batch([(records, value)])
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 1553, in write_real
    comodel.browse(
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5202, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 AssertionError: Invalid falsy real id
```
opw: 5922525
upg: 3889582
tgb: 2449

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

Task Adhoc side: 56583
Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view

The error was this one:

Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29)

Forward-Port-Of: odoo/enterprise#100457

## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates
Before this commit, it was possible to have `Planning Slots`
with `Sync Shifts and Rental Orders` whose dates were different
from the `Rental order`.

This commit makes sure that all dates are always synced:
- If the `Rental Order` dates are changed then all
`Planning Slots`' dates changed to the new dates.
- If a `Planning Slot` dates have changed then all
other `Planning Slots` and the `Rental Order` Dates
are changed to the new dates.

## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots
Before this commit, adding/removing a `Planning Slot` would not
change the `SOL quantity` and changing the `SOL quantity` would not
add/remove `Planning Slots` unless all slots are being deleted.

This commit makes sure that when the `SOL quantity` is
changed, the number of `Planning Slots` is changed accordingly,
and if a Planning Slot` was added/removed, the `SOL quantity`
would update accordingly.

Note: The new sync behaviour from `SOL quantity` is ignored for
`Products` with `hour UOM` because it is not clear yet how to update
the `Planning Slots` if the new quantity of hours doesn't span a full
rental interval.

## [FIX] sale_renting_planning: fix set multiple slots to resources
Before this commit, adding multiple `Planning Slots` at the
same time with the same `Role` can assign them to the same
`Resource` even if they conflict with each other.

This commit makes sure that when adding multiple `Planning Slots`
none of them would conflict with each other after being added.

task-5187356

Forward-Port-Of: odoo/enterprise#104771

**Steps to Reproduce:**
1. Open Payroll->Payslips->Pay Runs
2. Click on a Pay Run in Mobile View (Width < 600px).
3. Return to the previous view using the breadcrumb.
4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft')

**Bug Cause:**
The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback.

**Solution:**
Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout.

Task: 5971861

Forward-Port-Of: odoo/enterprise#108847

**Problem:**
When Billing a dropshipped PO, if the price of the bill 
is changed from the price of the Purchase Order,
the standard price of the product is not updated

**Steps to reproduce:**
- enable the dropshipping settings
- create a storable product with avco perpetual category
- in the inventory tab, select the dropship route
- in the purchase tab, set a vendor
- create and a confirm a quotation for this product
- on the linked purchase order, set a unit price of 100$ and 
confirm
- validate the dropship move
(- you can check on the product form that the standard price 
is now 100$)
- create a bill for the purchase order
- set the price to 90$ and confirm
- navigate to the product form

**Current behavior:**
The standard price is still 100$

**Expected behavior:**
It should be 90$

**Cause of the issue:**
When we validate the picking, action_done() is called on the moves .
Inside the action_done() override of stock_account, 
after the call to super, set_value is called on is_in 
and is_dropship moves 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L168-L169

Inside _set_value(), 
because the move is dropship, it's going to be added to 
products_to_recompute 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L277-L278

and then we're going to exit this iteration of the for loop. 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L285-L286
so basically we simply call the _update_standard_price() on the product.
https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/stock_move.py#L310
Because the product is avco, _update_standard_price is going to call _run_average_batch 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/product.py#L541

The value is not set on the dropship move but it's still used in the computation because for dropship move, we use _get_value()
https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/product.py#L382-L383
which will take into account the bills and POs if there are some.

But the problem is that, when we post the invoice we only call set_value on is_in moves
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/account_move.py#L42
So the standard price of our dropshipped product is not updated.

opw-5498878

Forward-Port-Of: odoo/odoo#250067

You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected.

Steps to reproduce
1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b),
model_b.x_studio_test(relation=other_model)`.
2. Create a related field on model_a and click the related icon for the test field.
3. The popover will now be displaying the fields for other_model instead of model_b.

Cause:
This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). 

Solution:
Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`.

opw-ticket 5459944

Forward-Port-Of: odoo/odoo#249185

Steps:
- Create a price list (or existing one)
- Create (or find) a product with only one variant
- Add price list rule for that variant (Should show as Variant:... in Pricelist listing)
- Go to pricelist listing, select the pricelist
- Edit price list rule - Remove the product
- Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id)

Related ticket:
opw-5411034

(Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view)

Description of the issue/feature this PR addresses:
Fix corrupted data
<img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" />

Current behavior before PR:
product_tmpl_id set to None
product_id / applied_on data stays the same

Desired behavior after PR is merged:
When product_tmpl_id is removed, reset the applied_on type back to 3_global

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

Forward-Port-Of: odoo/odoo#250531
Forward-Port-Of: odoo/odoo#249417

Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.

The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.

Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.

TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855

opw-5489862

Forward-Port-Of: odoo/odoo#246995

*: purchase_stock

Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a stock reference, even when the transfers are manually
created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.

Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were        
     created manually and not generated from any same source document like PO/SO.

Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `stock.reference`is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves
without a `reference_ids` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common stock reference.

After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `stock.reference`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a stock reference. This ensures each manual transfer creates its `own next operation` in multi-step routes.

Task-ID: 5242340

Forward-Port-Of: odoo/odoo#250385
Forward-Port-Of: odoo/odoo#235423