Issue:
----------------------------------------
When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback.

Steps to reproduce:
----------------------------------------
- Have Planning and Time Off installed
- Create a public holiday for another company
- Create an employee with no calendar
- Open Planning and try to add the new employee
- Traceback

Cause:
----------------------------------------
This commit 55ce1e3411d0693807d883ac159039b8141ff6b6 added the new method called `_get_flexible_resource_valid_work_intervals()` which will call `_leave_intervals_batch()` on `self.env['resource.calendar']`. In `_leave_intervals_batch()`, the resource list will contain the fully flexible employee and `self.env['resource.resource']`.

During the handling of the public holiday we created, we loop through the resource list. 
The first one is the flexible employee, but it gets skipped by the `continue` as it has a different company. Because of this the variable `tz` still equals `None`. 
The second resource is `self.env['resource.resource']` which doesn't validate the condition to be skipped. So it reaches the line
```py
tz = tz if tz else timezone((resource or self).tz)
```

But `tz` is still `None` and both `resource` and `self` are empty, so it gives `False` to the timezone constructor, which crashes.

Solution:
----------------------------------------
Add a default value to 'UTC' to handle this specific case.

opw-6107269

Forward-Port-Of: odoo/odoo#259404

### Issue before this commit:
When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic.

### Steps to Reproduce:
Create a computed many2many field.
Add it to a form view (can be invisible).
Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field.

### Cause of the Issue:
In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity.
When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity.

### With This Commit:
Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets.

opw-6122024

Forward-Port-Of: odoo/odoo#261093
Forward-Port-Of: odoo/odoo#260993

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#261316
Forward-Port-Of: odoo/odoo#259776

**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
  * Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
  * Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.

**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
  * Case 1 (Demand=10, Done=8):
    * Ordered = 8, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 12, Delivered = 12.

**Expected behavior:**
* Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.

 **Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157

CASE- 1
* When validating with *less quantity* and *no backorder*:
  * In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
  * If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
  * where it take  quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
  * As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.

CASE-2
* When validating with *more quantity* than demanded:
  * `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
  * The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
  * The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
  * In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
  → `qty_ordered += 2`  →  `qty_ordered = 12`  ✗  (surplus added to demand)
  → `quantity += 2`     →  `quantity = 12`      ✓
  * The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.

* After the fix:
  * Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.
    
*  NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
 to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully

Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
    <img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
  </div>

  <p><strong>After:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
    <img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
  </div>
</details>

---

opw-5874759

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

Forward-Port-Of: odoo/odoo#250587

How to reproduce:
- Select an employee with an overtime ruleset and work entries based on
attendances
- Create attendance with an approved overtime
- Go to "Work Entries" in Payroll, and regenerate the work entries for the
following day of the attendance
- A new overtime work entry is generated on the first day.

Reason:
Because of how regenerating work entries is done, the computed date for
searching overtime lines took into account the previous day (i.e. regenerating
a work entry for a tuesday in an UTC+1 timezone made it so the starting date
was on monday at 23:00:00), and since the _read_group only looked at the
date part of the time start without taking into account the hour, it
included the overtime of the previous day.

How it was fixed:
The domain now takes into account the timezone of the employee to generate the
domain for the _read_group to ensure the correct day is selected

Task ID: 5899657

Forward-Port-Of: odoo/enterprise#115032
Forward-Port-Of: odoo/enterprise#107266

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#260803
Forward-Port-Of: odoo/odoo#250160