Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
    - weight: 10 kg
- Create a delivery picking:
    - Add one unit of P1
    - Mark as “To Do”
    - Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0

Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
    - `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
    - `pack.shipping_weight` is 0 on creation.
    - The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13

opw-5357843

Forward-Port-Of: odoo/odoo#251216
Forward-Port-Of: odoo/odoo#238917

An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change

Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown

Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0

Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked

opw-5931355

Forward-Port-Of: odoo/enterprise#108495

There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request. But it returns a request object and then executes the delete asynchronously. This would cause a race condition on the init where we would trigger the init of the indexedDB at the same time as we were trying to delete it and it would hang for ~10 seconds before finally launching the POS.

The second more important issue is that after the reset there is a `localData = []`. This would cause the line in `synchronizeServerDataInIndexedDB` `JSON.parse(JSON.stringify(serverData));` to return an empty array so no new models would get created in the indexedDB and the POS would launch with an empty indexedDB.

This commit changes the `indexed_db.reset()` method to return a promise and awaits it before reinitialising the indexedDB. And resets the `localData` to `{}` which fixes the `synchronizeServerDataInIndexedDB`

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

Forward-Port-Of: odoo/odoo#246476

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

Forward-Port-Of: odoo/odoo#250115
Forward-Port-Of: odoo/odoo#249482

A component bought from a vendor and
dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to "ordered quantity", the `_eligible_for_stock_account` method will test if the related stock move are dropshipped https://github.com/odoo/odoo/blob/7436e0cfaf8d4b0c0e0390e8d6a3df404ba240f6/addons/stock_account/models/account_move_line.py#L31-L35 The value `is_dropship` is only set at the validation of the stock move. Due to the invoice policy, the receipt is not validated yet.

close #243015
This commit will rather use the helper `_is_dropshipped()` that only rely on the location and not on the state.

This commit also clean and reenable the related tests.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#249134
Forward-Port-Of: odoo/odoo#245930

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

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#109121
Forward-Port-Of: odoo/enterprise#101579

Problem:
-------
In several scenarios, Worked Days are incorrectly computed when the employee
has no contract or when the contract does not fully overlap with the payslip
period.

Case 1:
- Create an employee without a contract
- Create a payslip for this employee for the current month:
You'll see X days of attendance (= today until the end of the payslip period)
and Y days of out of contract (= number of days from the start of the payslip period until today)
- Create a payslip for this employee for the previous month:
you'll see ( Z_prev + Y )  days out of contract ( Z_prev = number of working days in the previous month)
- Create a payslip for this employee for the next month:
you'll see Z_next days of attendance (Z_next = number of working days in the next month)

Case 2:
- Create a new employee with a contract starting during the current month
- Create a payslip for this employee for the previous month
- Out-of-Contract days are incorrectly computed as:
  contract_start_date - previous_month_start.

Case 3:
- Create an employee with a contract ending during this month
- Create a payslip for this employee for the next month
- Out-of-Contract days are incorrectly computed as:
  next_month_end - contract_end_date.

Solution:
--------
When generating work days lines:
- Explicitly handle employees without a contract.
- Use adjusted date bounds when the contract does not overlap the payslip
  period.

Several tests were added to cover these scenarios, as well as the tests the corresponding commit
in odoo/odoo (PR odoo: 241978)

task-5430759

Forward-Port-Of: odoo/enterprise#109103
Forward-Port-Of: odoo/enterprise#103207

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

In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is not applicable to physical copies.

Previously, this logic failed during guest checkouts because the partner initially associated with the order is an archived public user. The persistent partner is only created/assigned after the address form is submitted.

This commit:
- Overrides `_create_or_update_address` instead of `_handle_extra_form_data` to ensure the paper format preference is saved on the correct, newly generated partner.
- Updates `_prepare_address_form_values` to correctly load existing preferences from the partner for registered users.
- Ensures the `l10n_tw_edi_is_print` flag on the Sales Order stays in sync with the partner's preference.

Task-5912985

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

Forward-Port-Of: odoo/odoo#250651
Forward-Port-Of: odoo/odoo#247961

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

…bcontracted

**Problem:**
Landed cost added on the receipt of a subcontracted product
do not increase the valuation of the product and do not create 
account move lines.

**Steps to reproduce:**
- create a tracked product with avco perpetual category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product at a unit price 
of 1$ with the same partner as the subcontractor of the bom
- validate the receipt
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- navigate to inventory/reporting/stock
- search for your product and click on the unit cost

**Current behavior:**
1) the valuation of the product was not increased by the value 
of the landed cost
2) open journal items : no account move lines were created for the 
landed cost

**Expected behavior:**
1) the valuation of the product should have been increased:
in the unit cost view, the SBC move should have gone from a 
value of 10 to 20
2) account move lines should have been created with a value 
of 10

**Cause of the issue:**
both issues come from the fact that when creating the 
stock valuation adjustment line, the move linked is the receipt move
when it should be the move of the subcontracted MO linked to the 
receipt.

**fix:** 
if we create the adjustement line with move_id as the move of the MO
(instead of the move of the receipt as it is the case currently) : 
when button_validate is called on the landed cost : 
- when using the remaining quantity, it will be the correct one 
(in our case 10, instead of 0 for the move of the receipt because it's 
actually an internal move) so the account move line are going to 
be created
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L129-L130
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L372-L373
which solves problem 2) 

-  when calling _set_value on the move (which will be the move of 
the MO thanks to this fix), 
https://github.com/odoo/odoo/blob/064407d32f998ceb08601f9e0a6356c94ad10347/addons/stock_landed_costs/models/stock_landed_cost.py#L152
get_value_data will call _get_value_from_extra,
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_account/models/stock_move.py#L392
which uses _get_landed_cost to fetch the landed cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L18
before this fix the landed cost created from the receipt were linked to 
the receipt move so they were not fetched inside _get_landed_cost
which caused problem 1) but now the move_id of the adjustment lines 
is the move of the MO so they are fetched inside _get_landed_cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L7-L12
So now the adjustment lines do impact the valuation of the move of 
the MO which solves problem 1)

opw-5723126

Forward-Port-Of: odoo/odoo#248469

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

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

How to reproduce
------
1. Open the Marketing Automation app
2. Create a new campaign
3. Click on Add new activity to create a new activity (in the previously created campagin)
4. Set the Activity Type to email
5. In the Mail Template option, select or create a mailing
6. Open the selected/created mailing (using the Templates smart button)
7. Click on the gear icon and then click Delete (either one or multiple together)

DEMO: https://www.awesomescreenshot.com/video/50021531?key=18a341a6939e6ff8deb847fc251db570

Current behavior
-----
Odoo Server Error is displayed.

Expected behavior
------
Normal user error indicating that the mailing(s) being deleted is still linked to an activity (or marketing campaign).

Cause
------
When formatting the user error, we used the attribute `name`, to
get the mailing's display name, which does not exist in `mailing.mailing`
model. Therefore, a KeyError is raised.
The `name` attribute was an attribute in a class named `UtmSourceMixin` in
the utm module, of which `mailing.mailing` was inheriting. In saas-19.2,
that class was removed and hence the `name` is no longer available for
`mailing.mailing`.
The commit in which the metioned class was removed is:
https://github.com/odoo/odoo/commit/93f8bb821ab86612d95d93ae0fdca5a08a12e2d5
(See utm_source.py)

Solution
------
Change the `name` to `mailing.display_name`.
DEMO: https://www.awesomescreenshot.com/video/50049334?key=a34a525ef38bdf2dc8037f2dcfa68761

task-5999999

The rounding of time was not correct. I was always flooring, but before
the new duration the rounding was depending of the precision of the
duration. The rounding has been restored as before and put in
formatDuration.
formatFloatTime has been modified to use formatDuration and now take
the same options (specify the unit of time of the value).

The graph view and list view didn't extract the otpions from the fields
with widget. Now, they get the options and give them to the formatter.

The widget was showing the seconds by default, but it doesn't match with
the behavior of the DateTime widget. It has been changed and now the seconds
are shown only if the options 'showSeconds' is true and it's false by default.
The impacted views has been restored as before the original commit.

The options of float_time widget couldn't take falsy values, now it can.

an improvment has also been done: the popover on the float_time widget
doesn't show up if the input value and the formattedValue are the same.

followup of TASK-5347051

Steps to reproduce
-----
- Enable locations & by products
- Create 4 locations
	- View A of type view (parent: Stock)
	- View B of type view (parent: Stock)
	- Storage A of type internal location (parent: View A)
	- Storage B of type internal location (parent: View B)
- Create a "Manufacture to A" route
	- Rule 1: Manufacture, Stock -> Stock
	- Rule 2: Push To, Internal Transfer, Stock -> View A
- Create a "By Products to B" route
	- Rule 1: Push To, Internal Transfer, Stock -> View B
- Create a "Bonus" product with route "By Products to B"
- Create a "Finished" product with route "Manufacture to A"
	- BoM with "Bonus" as by product
- Create a MO for Finished, and produce it
- Open the linked transfers' list view
- Open the "Bonus" transfer

> "Destination Location" states View B

- Open the line's details (hamburger button)

> "Store To" states View A/Storage A

Cause
-----
When retrieving the location in

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282

we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260

This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371

which might not be a child of the location.

Solution
-----
By removing the context key, locations get populated as such

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330

This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location.

-----
Ticket:
opw-5359945

Forward-Port-Of: odoo/odoo#250147
Forward-Port-Of: odoo/odoo#247403

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