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

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

### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).

### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:

AttributeError: 'NoneType' object has no attribute 'invoice_date'

This raises an RPC_ERROR and breaks the mail composer / send flow

### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.



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

Forward-Port-Of: odoo/odoo#250167

Issue:
Sending PUE payments to CFDI/SAT is no more suitable

Step to reproduce:
- In a Mexican company
- Create an invoice (Invoice A)
- Add a line
- Set Payment Terms to "Immediate payment"
- Confirm
- Duplicate (Invoice B)
- Confirm
- Duplicate again (Invoice C)
- Set Payment Terms to "30 days"
- Confirm
- Go to Invoice A
- Pay it. It should appear as "Paid"
- Send it to CFDI
- Go to Accounting > Customer > Invoices
- Select Invoice B and C
- Pay and select the "Group Payments". They should appear as paid.
- In every invoice, click the "Update Payment" button

Current behavior:
- In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI
- In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C

Expected behavior:
- It shouldn't be possible to send payment for invoice A to CFDI.
- Payment for invoice B shouldn't be sent to CFDI

Cause:
Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI.

Solution:
Disable the force sending to CFDI

About tests:
l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess.

opw-5381600

Forward-Port-Of: odoo/enterprise#109306
Forward-Port-Of: odoo/enterprise#104628

### Issue:
No tax will be applied if in taxes, fiscal position is set to all.

#### Steps to reproduce:
1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder.
2- Set Domestic FP to be applied automatically, and set the country to `US`.
3- Create a Partner with `US` country_id.
4- Create a product, and apply the created tax to sale taxes.
5- Create a SO with created partner and the created product.
6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic.

Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp.

### Cause:
In this line, if no `tax_ids` is set, it means fp has not tax_ids:
https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158

However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation.

In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped.

### Fix:
This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set.

opw-5463245

Forward-Port-Of: odoo/odoo#244155

Issue:
---
Due to this issue, price per unit is not shown correctly in case of packaging.

Steps to reproduce:
---
1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1.
2- Create a packaging of 0.5 kg, and add it to product in Sale tab.
3- Navigate to the shop and add 0.5 kg of the product to cart.
4- Navigate to the cart.

Expected: The line price/unit should be 2.60/kg.
Current outcome: It's shown 1.30/kg.

Cause:
---
Currently `_get_base_unit_price(product_price/line.product_uom_qty)` is shown to user as price/unit.
`product_price` is calculated using `_get_cart_display_price()` which returns each line's `subtotal` or `total`.
In our case, it will be `_get_base_unit_price(1.30/1)`, having base_unit_count set to 1, we will have 1.30 which is wrong.

Fix:
---
We would need to divide the line price by `product_qty` instead of `product_uom_qty`.
Then in our example we would have:
`_get_base_unit_price(1.30/0.5) = 2.60`.

opw-5973097

Forward-Port-Of: odoo/odoo#251501

Steps to reproduce:
- Create a storable product P1 with the following BoM:
    - Component: C1
    - Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"

Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)

Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418

The function will  sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659

After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587

opw-5947687

Forward-Port-Of: odoo/odoo#251352
Forward-Port-Of: odoo/odoo#249336

**Issue 1:**

Steps to Reproduce

- Click on the More options button in the power buttons.
- The powerbox opens, but the editor loses focus and the button receives focus.

Description of the issue:

- After clicking the power button, the button becomes focused and the editor loses focus.

Solution

- When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused.

**Issue 2:**

Steps to reproduce

- Click More options in the Power Buttons to open the powerbox.
- Start typing `heading`.

Description of the issue:

- The powerbox does not filter commands and continues to show all commands.

Cause:
- In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true.
- `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`.
- Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered.

Solution:
- Introduced `openSearchPowerbox` in `searchPowerboxPlugin`.
- Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`.
- Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress.

task-5485088

Forward-Port-Of: odoo/odoo#249844
Forward-Port-Of: odoo/odoo#244454