**Issue**
When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE.

**Steps to Reproduce**
1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock.
2. Create and confirm a new Sale Order.
3. Click on the Delivery smart button.
4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder.
5. Generate the Delivery Guide.
6. Open the generated DTE XML and observe that the quantity is incorrect.

**Root Cause**
The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount.

**Fix**
Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE.

Opw-4892276

Forward-Port-Of: odoo/enterprise#89633

**Problem:**
when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating

**Steps to reproduce:**
- create two products tracked by lot (comp A and comp B)
- set an on hand quantity for both
- create a storable product (final product) and create a BOM
- in the BOM add comp A and comp B
- create an internal transfer for 1 final product and 1 comp B
- click on "mark as todo"
- open this transfer in barcode, we see that the two lines from the comp B are grouped
- scan the source location, click on +1 and +2 button to fulfill the quantities and validate

**Current behavior:**
a backorder is created

**Expected behavior:**
no backorder should be created as we entered the right quantities of the picking

**Cause of the issue:**
the lines from comp B should not have been grouped in the barcode picking.
When doing the same scenario but with product not tracked those lines are not grouped

opw-4998766

Forward-Port-Of: odoo/enterprise#93947
Forward-Port-Of: odoo/enterprise#93262

If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on the order line and the price unit and price with taxes are different (although no tax recorder on the line).

Steps to reproduce:
-------------------
* Create a fiscal position and assign no tax to it
* On the pos config, add this fiscal position and the domestic one to the available fiscal positions
* Open pos session
* Select a product that has a 15% tax
* Change the fiscal position to the one just created
> Observation: We still see that the tax is computed based on the 15%
* Pay the order
* Go see the order in backend
> Observation: price unit: 100, no tax, price with taxes 115

Why the fix:
------------
A recent refactoring happened on the accounting side related to fiscal positions: https://github.com/odoo/odoo/commit/9a97157920c845120861dda49d81d3150e015974

https://github.com/odoo/odoo/blob/e284dfd80bde632e6446fc0b8d3276689da35200/addons/account/models/partner.py#L155-L163

The behavior after this refactoring is the following: When changing fiscal position:
- If the original tax is available for the fiscal position, we use it
- If the original tax is not available but the fiscal position has an available tax that is set to be replacement for the original one, we use the replacement tax
- If the original tax is not available but the fiscal position has an available tax which is NOT a replacement for the original one, we keep the original one
- If the fiscal position has no tax available, we remove the tax

In this fix we apply the same logic inside the pos.

Without the fix we would keep the original tax in the frontend but when passed in the backend the tax with fiscal position was recomputed with the logic from accounting. This explained the difference we observed.

opw-4978056

Forward-Port-Of: odoo/odoo#223164

This PR is made of 3 small commits:

- `[FIX] iot_drivers: fix blank homepage after checkout`
  Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can end up with the old Python code running but the updated JS code loading in the browser. This can lead to a blank screen as a traceback occurs trying to read the MAC address.
  
  We fix this in two ways:
  - A quick fix, which is just making the JS code robust to the missing value to avoid crashing.
  - A proper fix that will require a new image, as it modifies the `odoo.service` file to add `rc-local.service` as a dependency. This means Odoo will not start until `rc.local` has finished executing.


- `[FIX] iot_box_image: set http_interface explicitly`
  From Odoo 19.0, a warning is logged when your `http_interface` config
  setting is not explicitly set. From Odoo 20.0, the default value will
  change from `0.0.0.0` to `127.0.0.1`, which would break the IoT box as
  it would only listen to localhost requests.
  
  To fix this we explicitly set the `http_interface` value to `0.0.0.0` in
  `odoo.conf` so that the IoT box will listen to all requests.


- `[FIX] iot_drivers: use FETCH_HEAD when checking out`
  The current 25.07 IoT box image cannot checkout to 19.0 databases due to
  an issue where the `git reset origin/19.0 --hard` command fails. In the
  other places where we use `git reset` in the IoT box this was fixed by
  using `FETCH_HEAD` (an alias for the last branch that was fetched).
  
  In this commit we apply the same fix to the `upgrade.py` checkout.

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