**Steps to reproduce:**
- enable multi-step routes setting.
- navigate to warehouse management/locations create a new location
(the "test location").
- select "internal location" for the location type.
- select WH for the parent location
- navigate to warehouse management/warehouses and select the warehouse
corresponding to WH.
- set the warehouse in 3 steps delivery.
- click on the routes smart button.
- click on the "deliver in 3 steps (pick+pack+ship)" route.
- add a rule, for the action select "push to", for the operation type 
select "internal transfers", for the source location select the "test 
location" you just created and for destination location select "WH/Output".
- save.
- create a storable product and set an on-hand quantity
- create a new sale order for 1 quantity of this product and confirm it
- click on the picking smart button, change the destination location to the
test location and validate
- open the sale order and change the quantity to 3


**Current behavior:**
A new picking is created from stock to packing zone (which is the 
expected behavior) but the quantity is 1 

**Expected behavior:**
The quantity should be 2.
If we only increase the quantity by 1 on the sale order it does not even 
create the new picking

**Cause of the issue:**
The warehouse_id field is invisible in stock.rule form view when the 
action is push. Therefore, the rule is created without a warehouse_id.
Also, moves created from a rule have the same warehouse_id as the rule. 
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275
So, when we validated our first move (from stock to the test location), 
this created a second move (from test location to output) that does not 
have a warehouse id (because it was created from our own push rule that
we created).
When we update the quantity of the sale ordre line, 
_action_launch_stock_rule calls _get_quantity_procurement to compute 
the current quantity on the moves.
This method then calls _get_outgoing_incoming_moves to get the initial 
move created from the rule. In this case this should return only the 
first move created.
But because the second move does not have a warehouse_id, it's rule.id
is added to triggering_rule_ids.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317
And the move is later added to the outgoing moves that will be returned.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329

So the two moves are returned and the sum of the quantities of the moves
is 2 instead of 1.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294
So the product quantity for the procurement will be 1 (3-2) 
instead of 2 (3-1).
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386

opw-5039249

Forward-Port-Of: odoo/odoo#229332
Forward-Port-Of: odoo/odoo#227421

Before this commit, a maximum call stack traceback occurred when accessing the chat tab of the messaging menu on iOS when many chats were present. On chrome and firefox, no traceback occurred, but the menu took a long time to open.

Threads shown in the messaging menu rely on the `menuThreads` store property, which had two issues:
- It was a computed field done on the many side of the relation, while relying on the inverse (thread) side would be much faster.
- The sort function was triggered for each thread inserted or removed from the relation. The sort function is not trivial, and accessing sort fields through the reactive proxy is very slow.

This commit fixes the issue by:
- Updating the `menuThreads` property to use an inverse instead of a complex compute.
- Debouncing the array sort to ensure it is executed only once when the relation is properly filled.

task-4794325

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

Versions
--------
- 18.0+

Steps
-----
1. Enable rental transfers;
2. have a rental product with a kit BoM;
3. create a subscription order in the Rental app;
4. add the rental product;
5. confirm order;
6. validate deliveries;
7. close the subscription.

Issue
-----
Invalid SQL command, cannot return more than was delivered.

Cause
-----
When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line.

For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute.

This causes an error, as `qty_returned` is non-zero.

Solution
--------
The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0.

opw-4833280

Forward-Port-Of: odoo/enterprise#96179
Forward-Port-Of: odoo/enterprise#88691

> [VBAL] Supported payment methods inner content (in the header): You can adjust the height, but this moves the elements on the right outside of the screen (can be fixed by zooming/unzooming on the screen but not user friendly): https://drive.google.com/file/d/1J0Vp050kDzx_jnPVfWyHxy6GpQ6GvpBX/view?usp=drive_link


### [FIX] website: re-adapt extra menu on size changes of menu and navbar

When the size available or needed for the the top menu changes (for
other reasons than a window resize), the menus were not auto-hidden.
They were auto-hidden only if the window changes size.

If the user is editing the website and increase the width of some
element in the header, it may overflow. The overflow disappears only
once the user changes the size of the window (which causes some menu to
be hidden again).

This commit fixes that by replacing the listener for a window `resize`
event by a `ResizeObserver` that observe the sizes of the navbar, the
menu and the menu's siblings.

Steps to reproduce:
- Open website builder
- Add text in the header until it gets too large
- Bug: the last menu is not moved to the dropdown to make more space
  available

task-4367641

### [FIX] website: move selection with menu when auto-hiding menus

When some menu are moved to be hidden in the dropdown, if the selection
is inside a moved menu, it was lost.

This commit fixes that by opening the dropdown and moving the selection
if it is in a menu moved to the dropdown

Steps to reproduce:
- Open website builder
- Add text in the label of a menu until it is moved to the dropdown
- Bug: the selection is lost, keep writing does not write anywhere

task-4367641

### [FIX] website: remove selection in dropdown when it closes

When the user has the selection inside a dropdown that closes, the
selection was kept. If the toolbar was shown on the selection, then used
to stays floating where the selection used to be.

This commits listen for the closing of the dropdown to remove the
selection if it was in the dropdown.

Steps to reproduce:
- Open website builder
- Click on the user's name to open the dropdown
- Select some text in the dropdown (the toolbar should appear)
- Press "esc" (the dropdown should close)
- Bug: the toolbar is left hanging where the selection used to be

task-4367641

Versions
--------
- 17.0+

Steps
-----
1. Set currency rounding of EUR to 1.0;
2. use the currency on a website pricelist;
3. go to a product page in /shop;
4. open the url in a new session.

Issue
-----
From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals.

Cause
-----
The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element.

Solution
--------
Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`.

For the product configurator, store the currency precision in the `.js_price_total` element's dataset.

Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date.

opw-4996878

Forward-Port-Of: odoo/odoo#229416
Forward-Port-Of: odoo/odoo#224429

`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted:

```SQL
pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN ir_model_data d ON d.res_id = c.id AND d.model = 'res.country' AND d.module = 'base' AND d.name IN ('cl', 'co')
+----------+
| ?column? |
|----------|
| COLOMBIA |
| Colombia |
+----------+
```

Note: in this specific, the change is clearly an error introduced in the data. Still, the error it produces (which follows) can be avoided by referring to the xmlid, instead of the record name.

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
  File "<decorator-gen-6>", line 2, in new
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 226, in load_module_graph
    load_data(env, idref, 'update', kind='data', package=package)
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 79, in load_data
    tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 624, in convert_file
    convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 680, in convert_csv_import
    raise Exception(env._(
Exception: Module loading l10n_cl failed: file l10n_cl/data/res.bank.csv could not be processed:
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
```

upg-3131231

Forward-Port-Of: odoo/odoo#229435
Forward-Port-Of: odoo/odoo#229218

**PROBLEM**
Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.

**STEP TO REPRODUCE**
1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company).
2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests).
3. Switch to the be company.
5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method.
6. Go to the delivery order, and validate it.
7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance.

**CAUSE**
We don't send any info about insurance in the api requests.

**FIX**
Computing and sending the insured amount, only if the insurance percentage is not null.
If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price.

**TESTS PROBLEM/FIX**
The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price.
Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this.
Assertion regarding the delivery price were restored.

The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM).
Changing the picking date to, two day after, at noon works.

`test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow.
Some code in it was refactor into inner function to avoid boilerplate.

Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01.

opw-4989281

Forward-Port-Of: odoo/enterprise#93105

**Issue description:**
The logic introduced in #127196 adds default taxes from "other" companies to products created without a specific company.
However, because child companies (branches) share taxes with their parent company, when creating a new product using the parent company and setting a specific tax (different from the default), the default tax was incorrectly added back to the product.
This happened because the logic considered the branch an "other company" and applied its default tax.

**FIX:**
Exclude branch companies from the domain when we set the default tax of other companies on the product.

**Steps to reproduce:**
1. Create a branch company. (It will automatically have the same default tax as its parent).
2. With the parent company selected, create a new product, leaving the 'Company' field empty, and change its sales tax to any tax other than the default, and save.
3. Notice that the default tax is set again on the product.

opw-5094415

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

Forward-Port-Of: odoo/odoo#229066

Versions
--------
- 18.0+

Steps
-----
1. Enable rental transfers;
2. have a rental product with a kit BoM;
3. create a subscription order in the Rental app;
4. add the rental product;
5. confirm order;
6. validate deliveries;
7. close the subscription.

Issue
-----
Invalid SQL command, cannot return more than was delivered.

Cause
-----
When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line.

For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute.

This causes an error, as `qty_returned` is non-zero.

Solution
--------
The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0.

opw-4833280

Forward-Port-Of: odoo/enterprise#96179
Forward-Port-Of: odoo/enterprise#88691

**Note: issue not reproducible in runbot, but in fresh database** 

**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data

**Observation:**
- You will receive traceback

```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```

**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569

https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628


- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback

**Fix:**
- make demo data independent of any localization

opw-5048417

**Steps to reproduce:**
- Have a preset that requires time slots
- Make the slots_per_interval 1 and the interval_time long enough
- Go to the self order, make a purchase and select a slot
- Make another purchase
- The slot we chose before is still showing and available

**Why the fix:**
Once the capacity of a time slot has been reached, we should not allow customer to chose it.
This behavior occured for 2 reasons:
- In the xml file where we declare this select, we did not take the fact that a slot could be full into account, leading to it always being showed. This is now done using the isFull attribute, like it is done in the regular PoS.
- This same isFull was not correctly set, as there was a mismatch in slots timezone and format. When we retrieved them from the server, they were in UTC timezone, but the current slot we were working with was in the locale timezone. It is now converted to UTC to check if we already hit max capacity. Before this, selecting a timezone was actually selecting the one that was two hours earlier (for Belgium).

With this commit, the values that reached max capacity will not be displayed on the select for the time slots anymore.

opw-5092888

### Steps to reproduct:

- Create 2 products: Final Product (FP), Kit Product (KP)
- On KP add a Color attribute with 2 values: Blue, Red
- Create a KIT bom for KP wtih 2 operations:
    - OP: paint it Blue, apply on Color: Blue
    - OP: paint it Red, apply on Color: Red
- Create a bom for FP with only one component line:
    - 1 x Red Kit Product
- Create a MO for 1 unit of FP
#### > The operation was not created using the kit bom

### Cause of the issue:

Even if the bom exploded to find the operations to add on the MO: https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_production.py#L579-L599 The `_skip_operation_line`:
https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_routing.py#L164-L174 is checking if the product of the main bom has the attributes of the operation rather than the kit product used as component.

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

Forward-Port-Of: odoo/odoo#228032

**PROBLEM**
Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.

**STEP TO REPRODUCE**
1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company).
2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests).
3. Switch to the be company.
5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method.
6. Go to the delivery order, and validate it.
7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance.

**CAUSE**
We don't send any info about insurance in the api requests.

**FIX**
Computing and sending the insured amount, only if the insurance percentage is not null.
If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price.

**TESTS PROBLEM/FIX**
The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price.
Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this.
Assertion regarding the delivery price were restored.

The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM).
Changing the picking date to, two day after, at noon works.

`test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow.
Some code in it was refactor into inner function to avoid boilerplate.

Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01.

opw-4989281

Forward-Port-Of: odoo/enterprise#93105

**Issue description:**
The logic introduced in #127196 adds default taxes from "other" companies to products created without a specific company.
However, because child companies (branches) share taxes with their parent company, when creating a new product using the parent company and setting a specific tax (different from the default), the default tax was incorrectly added back to the product.
This happened because the logic considered the branch an "other company" and applied its default tax.

**FIX:**
Exclude branch companies from the domain when we set the default tax of other companies on the product.

**Steps to reproduce:**
1. Create a branch company. (It will automatically have the same default tax as its parent).
2. With the parent company selected, create a new product, leaving the 'Company' field empty, and change its sales tax to any tax other than the default, and save.
3. Notice that the default tax is set again on the product.

opw-5094415

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

Forward-Port-Of: odoo/odoo#229066

Versions
--------
- 17.0+

Steps
-----
1. Set currency rounding of EUR to 1.0;
2. use the currency on a website pricelist;
3. go to a product page in /shop;
4. open the url in a new session.

Issue
-----
From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals.

Cause
-----
The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element.

Solution
--------
Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`.

For the product configurator, store the currency precision in the `.js_price_total` element's dataset.

Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date.

opw-4996878

Forward-Port-Of: odoo/odoo#229416
Forward-Port-Of: odoo/odoo#224429

### Steps to reproduce
- In `l10n_mx_edi/tests/common.py`, change `cls.frozen_today` to any value between `2025-10-01 00:00:00` and `2025-10-01 05:59:59`
- Run the `:TestCFDIInvoiceSale` tests
- The tests fail because the payment policy is PPD whereas the expected XML has PUE

### Diagnosis
The `sale.advance.payment.inv` wizard creates an invoice with `invoice_date_due = '2025-10-01'` but at post, we assign `invoice_date = '2025-09-30` due to this line:

https://github.com/odoo/enterprise/blob/1f3c82635ee162987cf08490d447ad6d4121be4d/l10n_mx_edi/models/account_move.py#L838

As a result, the due date is in the month after the invoice date, so PPD is used as payment policy.

### Solution
Force PPD by setting the due date to be 40 days after the invoice date, for consistency with the tests in `l10n_mx_edi`.

#### Other solutions considered
We could change the timezone in the context of the wizard, to make sure the due date is exactly the same as the invoice date, and keep PUE everywhere.

runbot-233041

### Issue:

#### Steps to reproduce:
1- Activate routes & locations and enable Reception Report
2- Enable Show reception report at validation from operation type: receipts
3- Create a product with vendor. Put 2 unit on `WH/Stock/Shelf1`
4- Create a Sales Order for 3 units.
5- Create a PO for 1 unit and validate/receive.
6- On the Reception Report, click Assign to link incoming to sales pick
7- Open the sales pick in a new tab, observe there are 2 moves which first one is 1 and 2nd one is 2
8- On the reception report, click Unassign, then Assign again

Back on the Pick, only 1 move (the one with quantity of 2) is reserved; checking availability reserves nothing although stock exists.

#### Cause:
When unassigning from the Reception Report, the system incorrectly unreserves stock that was already in `Shelf1` instead of unreserving the incoming move which the location_id is `WH/Stock`:

User clicks Unassign on the Reception Report.
`report_stock_reception.action_unassign()` is invoked.
That calls `stock_move._do_unreserve()`.
`_do_unreserve()` unpicks quants referenced by the `move.move_line_ids`.
At this moment one of the `move_line_ids` points to `WH/Stock/Shelf1`, so `_do_unreserve()` removes the reservation from that `shelf1` quant.
Consequence: `shelf1` stock(which should have remained reserved) becomes free. The receipt quant at `WH/Stock` remains reserved/ unavailable.

When the user clicks Assign again, the system cannot reserve because it is alreade reserved by another move and therefore it is unavailable.

#### Root cause:
Now we look earlier in the flow to see why the move had a move_line pointing to `WH/Stock/Shelf1` in the first place. Earlier, in `report_stock_reception.action_assign` in the first assign:
We create a new move from current outgoing move:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/report/report_stock_reception.py#L224-L231 And we link current move_lines to the new move:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/report/report_stock_reception.py#L245-L259 new_out.move_line_ids now contains move lines for multiple source locations, here in our case `[WH/Stock/Shelf1, WH/Stock]` The loop in above code does not check `move_line_id.location_id` when selecting lines. The first matching line in the iteration can be the `shelf1` one, so the code links the `shelf1` move_line to out instead of the `WH/Stock` move_line, which is a mismatch and causes the out move having different location with its move_line, which later will going to cause problem is unassign as explained.

### Fix:
We can sort move_line_ids in a way that which line have the same location as potential ins' dest locations come first
as better candidates:
```diff
- for move_line_id in new_out.move_line_ids:
+ matching_locations = potential_ins.location_dest_id
+ for move_line_id in new_out.move_line_ids.sorted(lambda ml: ml.location_id not in matching_locations):
```

opw-4944047

Forward-Port-Of: odoo/odoo#226120

`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted:

```SQL
pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN ir_model_data d ON d.res_id = c.id AND d.model = 'res.country' AND d.module = 'base' AND d.name IN ('cl', 'co')
+----------+
| ?column? |
|----------|
| COLOMBIA |
| Colombia |
+----------+
```

Note: in this specific, the change is clearly an error introduced in the data. Still, the error it produces (which follows) can be avoided by referring to the xmlid, instead of the record name.

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
  File "<decorator-gen-6>", line 2, in new
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 226, in load_module_graph
    load_data(env, idref, 'update', kind='data', package=package)
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 79, in load_data
    tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 624, in convert_file
    convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 680, in convert_csv_import
    raise Exception(env._(
Exception: Module loading l10n_cl failed: file l10n_cl/data/res.bank.csv could not be processed:
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
```

upg-3131231

Forward-Port-Of: odoo/odoo#229435
Forward-Port-Of: odoo/odoo#229218

**PROBLEM**
Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.

**STEP TO REPRODUCE**
1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company).
2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests).
3. Switch to the be company.
5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method.
6. Go to the delivery order, and validate it.
7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance.

**CAUSE**
We don't send any info about insurance in the api requests.

**FIX**
Computing and sending the insured amount, only if the insurance percentage is not null.
If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price.

**TESTS PROBLEM/FIX**
The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price.
Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this.
Assertion regarding the delivery price were restored.

The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM).
Changing the picking date to, two day after, at noon works.

`test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow.
Some code in it was refactor into inner function to avoid boilerplate.

Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01.

opw-4989281

Forward-Port-Of: odoo/enterprise#93105

**Issue description:**
The logic introduced in #127196 adds default taxes from "other" companies to products created without a specific company.
However, because child companies (branches) share taxes with their parent company, when creating a new product using the parent company and setting a specific tax (different from the default), the default tax was incorrectly added back to the product.
This happened because the logic considered the branch an "other company" and applied its default tax.

**FIX:**
Exclude branch companies from the domain when we set the default tax of other companies on the product.

**Steps to reproduce:**
1. Create a branch company. (It will automatically have the same default tax as its parent).
2. With the parent company selected, create a new product, leaving the 'Company' field empty, and change its sales tax to any tax other than the default, and save.
3. Notice that the default tax is set again on the product.

opw-5094415

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

Forward-Port-Of: odoo/odoo#229066

Versions
--------
- 17.0+

Steps
-----
1. Set currency rounding of EUR to 1.0;
2. use the currency on a website pricelist;
3. go to a product page in /shop;
4. open the url in a new session.

Issue
-----
From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals.

Cause
-----
The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element.

Solution
--------
Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`.

For the product configurator, store the currency precision in the `.js_price_total` element's dataset.

Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date.

opw-4996878

Forward-Port-Of: odoo/odoo#229416
Forward-Port-Of: odoo/odoo#224429

Problem: When the available categories for a point of sale contain one parent category and its child categories and the parent category itself does not have any products, the code filters out the top categories as those that have no parent category. If, in such a case, no products belong to the parent category itself, the selected category is undefined which leads to a blank white screen and the javascript error visible on the console.

Purpose: If there are no top categories, the screen should ideally load the current category computed before. This fix leads to the one of the child categories being the selected category and the kiosk screen loads properly

Steps to Reproduce on Runbot:
1. Create a point of sale. Go to Settings, choose no presets and “Kiosk” in the self-ordering option.
2. Create a parent POS category and two child POS categories.
3. Ensure there are products belonging to the two child categories and none to the parent category
4. Open settings for the POS and choose only these three categories in the “Restrict Categories” section.
5. Go to the point of sale and open the kiosk. Click on “Order Now”. The white screen appears and the js traceback error is visible on the console

opw-5058245

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

Forward-Port-Of: odoo/odoo#229592
Forward-Port-Of: odoo/odoo#228651

steps to reproduce:
-------------------
1. Install website_sale_stock
2. Go to Website > Shop > Product (with inventory tracking enabled)
3. Click on Edit and remove the "Quantity" snippet
4. Save the changes

issue:
------
```
TypeError: Cannot read properties of null (reading 'value')
```
cause:
------
The code:
https://github.com/odoo/odoo/blob/2bd0b503e0b30a7a5e19736f7bdf89700ef1d3c6/addons/website_sale_stock/static/src/js/variant_mixin.js#L35-L36 unconditionally accessed `addQtyInput.value`
This raises an error when the "Quantity" snippet has been removed, since `addQtyInput` is null.

Reference PR: https://github.com/odoo/odoo/pull/223917

**NOTE**: During the conversion of website_sale public widgets to interactions,
the jQuery was replaced with an HTML element.
For e.g,
```python3
$addQtyInput ==> addQtyInput
```

Unlike jQuery objects, native elements can be null, but the code
still assumes its presence in several places,
https://github.com/odoo/odoo/blob/bdc888e78283f25067eb8cf5b79d4c30ad4b3469/addons/website_sale_stock/static/src/js/variant_mixin.js#L36
https://github.com/odoo/odoo/blob/bdc888e78283f25067eb8cf5b79d4c30ad4b3469/addons/website_sale_stock/static/src/js/variant_mixin.js#L43
https://github.com/odoo/odoo/blob/bdc888e78283f25067eb8cf5b79d4c30ad4b3469/addons/website_sale_stock/static/src/js/variant_mixin.js#L58

This leads to errors when the "Quantity" snippet is removed.

solution:
---------
Check if `addQtyInput` exists before accessing its value.

Co-Authored by loti@odoo.com

opw-5095486

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

**Issue**
A Manufacturing Order in *in progress* state can reuse a component
with a serial number that was already consumed in another MO.

**Steps to reproduce**
- Create two products A and B, both tracked by serial number.
- Create a BoM for product A: 1 A requires 1 B.
- Manufacture two units of product B with SNs 001 and 002.
- Manufacture one unit of product A using product B with SN 001.
- Create a new MO for product A:
   - Start the MO to set it *in progress*.
   - Assign product B with SN 001 again.
- Click on *Produce All* and observe that no error is raised.

**Cause**
The method `_check_sn_uniqueness` ignores raw moves that are not yet
picked ([see code](https://github.com/odoo/odoo/blob/73af26879b353cc17b2bed6ae5f0823a67f668ab/addons/mrp/models/mrp_production.py#L2634)).
In this flow, the component is still unpicked when the uniqueness check runs, so the error is never triggered. The move will only be marked as picked later in `_set_qty_producing` ([here](https://github.com/odoo-dev/odoo/blob/c96ae2ffd6c8064f783e57ac157defd351e4acfb/addons/mrp/models/mrp_production.py#L1301)), triggered by [`_set_quantities`](https://github.com/odoo-dev/odoo/blob/c96ae2ffd6c8064f783e57ac157defd351e4acfb/addons/mrp/models/mrp_production.py#L2198).

**Solution**
Remove the restriction on picked moves when checking for SN uniqueness. This makes the behavior consistent and avoids relying on the timing of the `picked` flag.

The first alternative considered was to always set `picked = True` before `_check_sn_uniqueness`, but that introduces complications since some logic still depends on the `picked` flag
([here](https://github.com/odoo-dev/odoo/blob/c96ae2ffd6c8064f783e57ac157defd351e4acfb/addons/mrp/models/mrp_production.py#L2189)). Moreover `_check_sn_uniqueness` is only called from
`_button_mark_done_sanity_checks`, which in turn is only used in `pre_button_mark_done` where `_set_quantities` is called. So, if the approach is to always set `picked = True` before calling `_check_sn_uniqueness` to avoid ignoring the move, then it is clearer and more efficient to simply remove the `picked` condition altogether.

Step to reproduce:
- Create an account group (e.g. Group_101 from 101 to 101)
- Create some AML in an account related to the previously created group (e.g. in 101501 Cash)
- Go to the Trial Balance
- In the Options, select "Hierarchy and subtotals"
- Add a filter including your group name (e.g. Group_101)
- Export to PDF

Current behaviour:
- no lines are displayed in the PDF as the backend uses only the account name to apply the filter

Expected behaviour:
- lines are displayed using group and account name to filter

Cause:
Filter was applied only on account name

Solution:
If hierarchy is enabled, display accounts where filter matches either account or group.
Group_id was a stored field until 18.0 and is now computed. The compute method use a SQL query. To avoid a second quite similar query, this commit creates a method called in both places which compute and execute the query. This method is called at several time, including:
- the creation of a record, before it is saved to DB. This implies the method should be able to compute groups for code of account not in DB.
- the search of an account based on his group. Which requires looking at all accounts.

Those constraints imply the needs to compute a query depending on parameters. In order to compute groups from account code of account not in DB, using `unnest` or `VALUES` is mandatory. However, a `Query` object couldn't be used here because the use of `unnest` (or `VALUES`) requires a composed alias with () which is "not a valid identifier". This led to the use of several SQL objects.

opw-4906593

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

### Issue: 
The partner ledger does consider lines without partners when calculating the initial balance.

### Steps to reproduce:
- Create an invoice in 2025
- Create an entry in 2025 without partner for the same amount
- Reconcile the two
- Open the partner ledger for 2025, everything is correct
- Change the dates to 2026, the amount of the initial balance ignores the entry but not the totals

### Cause:
The method `_get_sums_without_partner` is called for the totals, but not for the initial balance. Its purpose is to add the amounts of the lines without partners that were reconciled with lines with a partner.

### Solution:
Call `_get_sums_without_partner()` in `_get_initial_balance_values()` add the results before returning the initial balances.

As this is the same logic as `_query_partners()` we create a new method.

This method needs to be called with the dates of the initial balance in the options. So we create a duplicate of the options and input the new dates options.

opw-5068790

Forward-Port-Of: odoo/enterprise#95881

**PROBLEM**
Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.

**STEP TO REPRODUCE**
1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company).
2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests).
3. Switch to the be company.
5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method.
6. Go to the delivery order, and validate it.
7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance.

**CAUSE**
We don't send any info about insurance in the api requests.

**FIX**
Computing and sending the insured amount, only if the insurance percentage is not null.
If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price.

**TESTS PROBLEM/FIX**
The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price.
Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this.
Assertion regarding the delivery price were restored.

The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM).
Changing the picking date to, two day after, at noon works.

`test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow.
Some code in it was refactor into inner function to avoid boilerplate.

Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01.

opw-4989281

Forward-Port-Of: odoo/enterprise#93105

We need to know for each partner if it is a customer or a supplier, even
more for Romania[^1] where it is enfored and validated.
> 1. If the element SD.P.22 CustomerID is reported with value ”0”
  (zero), then the element SD.P.23 SupplierID must be different from ”0”
  (zero), meaning the identity of the partner from which the purchase was
  made (conventionally considered ”supplier”) is reported. Else if SD.P.22
  CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero),
  then is return a semantic validation error. (CustomerID and SupplierID
  can not be concomitantly 0 (zero))

In order to fix this, we don't use the Partner Ledger anymore to query
the balance per partner because it is removing the partners with 0
balance automatically.
To keep it simple, we query manually and locally, allowing to reduce the
number of queries from 3 to 1 for that part.

For the performance, the `|=` operator done in a loop has also been
removed, keeping the time complexity in `O(n)` instead of `O(n²)`.

opw-5122910

[^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t

### Issue:

In this bug, the workorder duration being set to duration_expected is causing issues in backorder.

To reproduce:
1- Create a Bill of Materials with at least two operations at two work centers
2- Create a manufacturing order and confirm it.
3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity.
4- In the second work order, the first operation is cancelled, Finish the 2nd operation
5- As you can see, the cancelled operation duration is set to expected duration which is wrong.

### Cause:

This issue is caused because of:
https://github.com/odoo/odoo/blob/8f0e40286da7b144bfa17880a257406dd8585e57/addons/mrp/models/mrp_production.py#L1774-L1779

Which if work.order.state is `cancel`, the duration will set to `duration_expected`.
This will eventually cause issue here:
https://github.com/odoo/odoo/pull/222075/commits/8f0e40286da7b144bfa17880a257406dd8585e57#diff-fac872ffb03b811c4976eb2e52991ec544265332df814d92cfda658a5b917423L348
which is fixed by not making the state into `progres` if the state is `cancel`.
But that doesn't fix the fact that the cancelled workorder has duration set and it might cause inconsistencies in manufacturing costs.

related:
#222075

opw-4931653

Versions
--------
- 17.0+

Steps
-----
1. Have a sale order with deliverable products & no payment terms;
2. confirm order & validate delivery;
3. create an invoice;
4. modify the delivery date;
5. save changes;
6. change product quantity of a line & confirm invoice.

Issue
-----
The delivery date got reset.

Cause
-----
The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`.

Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value.

Solution
--------
As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario.

In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write.

opw-4996654

A conflict occurs if a matrix question is set to "Mandatory answer" (questionRequired = True) and a table is also added to its description.

The issue is that when the system evaluates a required matrix, it gets the subQuestionsIds by looking for the first table within the question's wrapper. If a table exists in the description, the system incorrectly tries to retrieve the IDs from that table. This action throws a traceback because the descriptive table does not contain any sub-question data.

This commit fixes the issue by being more specific when looking for the table containing the subQuestionsIds. It adds a specific class to this table and uses it in the selector. An attribute selector, like 'table[data-sub-questions]', could also have been used as an alternative.

opw-4931881

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

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120