Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail.

**Steps to Reproduce:**
- Install Accounting and l10n_co_dian modules.
- Switch company to "CO Company".
- Create new customer invoice. (e.g;  Operation Type (CO) = Nota Débito que referencia una factura electrónica)
- Click on "Send" button. Ensure DIAN is selected in template and then send it.
- Error occurs.

**Error:**
AttributeError - 'bool' object has no attribute 'isoformat'

**Cause:**
The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1]

In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None.

**Fix:**
This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None.

[1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730
[2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496

sentry-6810908763

**Steps to reproduce:**

1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.

**NOTE**
-  You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
    invoice = env['account.move'].create({
        'move_type': 'out_invoice',
        'partner_id': 10,
        'company_id': env.company.id,
        'invoice_line_ids': [(0, 0, {
            'product_id': 16,
            'quantity': 1,
            'price_unit': 100.0,
        })],
    })
    invoice.action_post()
```

 **Issue:** 

`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.

 **Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73

- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />

- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />


**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.

**opw - 5083894**

Forward-Port-Of: odoo/enterprise#95103

**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.

**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05

**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891

**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.

opw-4931438

Forward-Port-Of: odoo/odoo#219310

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

Description of the issue/feature this PR addresses:

This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values.

This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case.

[This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it.

Refactored the test cases to avoid the redundancy in the setup process.

Steps to reproduce on runbot:
1. Set the pick up in store as the default delivery method by updating the sequence
2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here
3. Go to the cart and click checkout
4. The default pickup location will be set here
5. Click on Confirm
6. An error will appear saying the location was not set

opw-4954187

[This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4

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

Forward-Port-Of: odoo/odoo#227826