When user tries to validate Register Production/Serial in shop floor,
A traceback will appear.

Steps to reproduce the error:
- Install ``mrp_workorder`` and ``quality_control`` modules with demo data
- Go to Quality > Create a new Control point > Product: Table Top >
  Operations: Manufacturing > Save
- Create a new MO > Product: Table Top > Confirm > Shop Floor >
  Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate
- Click on 3 dots > Register Production/Serial > Validate
- Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate

Traceback:
``ValueError: Expected singleton: quality.check(1, 5)``

https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848
When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``.
The code expects only one record, which causes a traceback.

sentry-6839419788

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

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

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

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

Forward-Port-Of: odoo/odoo#223946

### 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#96125
Forward-Port-Of: odoo/enterprise#95881