The aim of this commit is to allow customer to make their batch payment
without facing a Traceback.

Context:
odoo/enterprise@35f5341b9b44cc16eaea311295a064189dd802cb introduced bug
during a badly handled forward port.
The method was removed in saas-18.3 in favor of a function. The forward-port
was half handled and now surfaces to Odoo's own production.

Generating a batch payment could generates the following Traceback:
```py
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal_sepa_ct.py", line 69, in _get_PstlAdr
    return super()._get_PstlAdr(partner_id, payment_method_code)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal.py", line 501, in _get_PstlAdr
    CtrySubDvsn.text = self._sepa_sanitize_communication(partner_address['state'][:35])
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.journal' object has no attribute '_sepa_sanitize_communication'
```

Task-id: None (internal issue)

Forward-Port-Of: odoo/enterprise#129084
Forward-Port-Of: odoo/enterprise#129006

**Problem:**
Duplicating a task, creating a task from a task template, or generating the next occurrence of a recurring task scrambles the dependencies between its sub-tasks: each copied sub-task carries the dependencies of a different sub-task instead of its own.

**Steps to reproduce:**
1. Enable Task Dependencies on a project.
2. Create a task with three sub-tasks and chain them: the second depends on the first, the third depends on the second.
3. Duplicate the task, or use "Create from template" if the task is a template.
4. Open the sub-tasks of the new task and look at their dependencies.

**Current behavior:**
The dependencies of the copied sub-tasks are shifted: the chain runs in the reverse order of the original one.

**Expected behavior:**
Each copied sub-task depends on the copy of the sub-task its original depended on, so the new task reproduces the original chain.

**Cause of the issue:**
`_create_task_mapping` builds the original to copy mapping by pairing `original_task.child_ids` with `copied_task.child_ids` positionally, on the assumption stated in its docstring that both recordsets share the same index order. They do not. `project.task._order` ends with `id desc`, so `child_ids` is read newest-first, while the copies are created by iterating the original `child_ids` in that same order. The copies' ids therefore ascend along the original list, and reading them back through `child_ids` returns them in the exact reverse order. `zip` then pairs each original with the copy of the sub-task at the mirrored position, and `_resolve_copied_dependencies` writes every `depend_on_ids` and `dependent_ids` onto the wrong copy. This affects every caller of that method: `copy`, the task template action, and the creation of the next occurrences of a recurring task.

**Fix:**
Sorting the copied children by id restores the correspondence because id order is the order in which the copies were created from the original list, an invariant that holds whatever `_order` does, whereas the previous code silently depended on `_order` producing the same sequence on both sides.

`test_duplicate_project_with_subtask_dependencies` and `test_recurrence_copy_task_dependency` were reading the copies by `child_ids` index too, which the mirrored mapping happened to satisfy, so they passed on a wrong result; they now index them in creation order as well.

opw-6386578

Forward-Port-Of: odoo/odoo#280893

Before this commit:
---

When [`absence_management`](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/res_company.py#L42) is enabled, a [scheduled action](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/hr_attendance.py#L645) automatically creates an attendance record at [**12:00:00 AM**](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/hr_attendance.py#L649) to mark negative extra hours for employees with missing attendance.

<img width="1147" height="474" alt="image" src="https://github.com/user-attachments/assets/833a4387-bc20-4bb7-817d-9ebe9afa7d71" />


If an employee later creates a leave covering this autogenerated attendance, the extra hours should be reset to `0`. However, this does not happen.

#### Video demonstration:
https://drive.google.com/file/d/1DTNQuQ3uV5nOUVMBazCDo0hBZbKJZUIW/view

This happens because the [domain](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_holidays_attendance/models/resource_calendar_leaves.py#L8) used to fetch attendances for [`_update_overtime`](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_holidays_attendance/models/resource_calendar_leaves.py#L34) compares the attendance `check_in` and `check_out` datetimes with the leave `date_from` and `date_to` datetimes.

The leave datetimes are aligned with the employee's working schedule. For example, if the working hours are **8:00 AM–5:00 PM**, the leave is stored from `{date, 8:00 AM}` to `{date, 5:00 PM}`. In contrast, the scheduled action creates the autogenerated absence attendance at **12:00:00 AM** (in the user's timezone). Since this attendance falls outside the leave datetime range, it is excluded from the domain, and `_update_overtime` is never called for it.

After this fix:
---

Instead of building the domain using the leave datetime range, the domain is built using the leave date range. This ensures that all attendances for the affected dates, including autogenerated absence attendances created at midnight, are included and their extra hours are updated correctly.

OPW: 6385811




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

Forward-Port-Of: odoo/odoo#281123

In this PR, https://github.com/odoo/odoo/pull/186250, the `product_uom` field was renamed to `product_uom_id`. However, in the `delivery` module, `product_uom_id` is dropped from the values when the delivery line is created. 
This causes `product_uom_id` to be recomputed.

This commit reintroduces `product_uom_id` in the values to prevent the field from being recomputed.

**Description of the issue/feature this PR addresses:**

For a strange reason, when a module inherits from `sale.order.line` and adds some computed fields with `precompute=True`. `price_unit`, `price_subtotal`, and `price_total` are computed incorrectly.

I have attached a module to demonstrate the issue.

https://github.com/user-attachments/assets/ebdd8695-c9d8-477b-b5cf-ba6d8d41e84a

Without this change, the test fails, and Odoo incorrectly recomputes the fields, as shown in the video.
<img width="1232" height="515" alt="image" src="https://github.com/user-attachments/assets/27370f1f-e7b7-4102-a606-0181b9d1a97a" />

When the ORM computes fields marked as `precompute=True`, in this function `_add_precomputed_values` https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/odoo/orm/models.py#L4836, `price_unit` is 0, but the records get `price_unit` from the product. Therefore, when [_compute_amount](https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/addons/sale/models/sale_order_line.py#L855) is called, the values are computed with an incorrect `price_unit`.
<img width="1087" height="940" alt="image" src="https://github.com/user-attachments/assets/92feadf0-7f93-4acc-8f1a-931db0655fcc" />

**Steps to reproduce the issue:**

- Install the attached module. [sale_precompute.zip](https://github.com/user-attachments/files/31265993/sale_precompute.zip)
- Configure a delivery carrier as free for orders over 1, and set the fixed price to 5, for example.
- Create a sales order and add a product with a value greater than 1.
- Add the shipping method. The price should be 0. In the sales order line, `price_unit` is 0, but `price_subtotal` and `price_total` are equal to 5 (the product's sale price).

For more context, this module is a simple example extracted from the OCA `product_secondary_unit` module, which adds a mixin with these fields: https://github.com/OCA/product-attribute/blob/18.0/product_secondary_unit/models/product_secondary_unit_mixin.py. In the `sale_order_secondary_unit` module, `sale.order.line` inherits from this mixin.

You can see the error in this PR: https://github.com/OCA/sale-workflow/pull/4535.
https://github.com/OCA/sale-workflow/actions/runs/32259842816/job/96090194021?pr=4535#step:8:509

I understand that this requires a deeper investigation into precompute to solve the underlying issue, but I propose setting `product_uom_id` in the `_prepare_delivery_line_vals` method as a temporary solution while the final solution is being investigated.

I understand that this field should not have been removed from `_prepare_delivery_line_vals`; the referenced PR only renamed the field and did not intend to remove the value from this method.
@Tecnativa @pedrobaeza @kcv-odoo @Feyensv coudl you please review this?

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

Forward-Port-Of: odoo/odoo#283551

Steps to reproduce:
===================
1. Add a video (e.g. a YouTube URL) to a product from the Sales app.
2. Open the product page on the website.
3. Slide the carousel to the video.

=> The video preview cover is blurry.

Root cause:
===========
The product images are rendered in a carousel (the shop_product_carousel template in ) where only the first slide  gets the "active" class; https://github.com/odoo/odoo/blob/af1b3ee2e7ac56a35bff5e030c3a831c27dbcf24/addons/website_sale/views/templates.xml#L3224-L3226 every other slide is "display: none".
A product video is rendered as a live <iframe> inside its slide, so when the video is not the first media its iframe loads while its container has no  dimensions (0x0). The embedded player then initializes as a small mobile player and loads a low resolution cover thumbnail (120x90), which looks blurry once the slide is shown at full size. Reloading only the iframe while the slide is visible fixes it, a full page reload does not.

Fix:
====
Defer loading the video iframes located on hidden slides their src is moved to a data-src attribute on start and restored once the slide becomes visible. The player then initializes at full size and loads a high resolution cover.

opw-6349394


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

Forward-Port-Of: odoo/odoo#282508
Forward-Port-Of: odoo/odoo#274002

### Issue before this commit:
When using the "Reverse and Create Invoice" feature on a posted invoice with a foreign currency and Cash Basis enabled, the expected Exchange Difference and Cash Basis tax entries are not generated upon the automatic reconciliation. The credit note is successfully created and reconciled with the original invoice, but the P&L exchange difference and the cash basis transition lines are completely missing. Currently, the only workaround is to manually reset the generated credit note to draft and re-post it, which forces the system to correctly calculate the currency rate differences and generate the missing entries.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Settings > Cash basis. Tick it and set as 'Base Tax Received Account' an account like 201000 Current Liabilities
3. Go to Chart of Accounts > search your account (ex. 201000 Current Liabilities) and be sure the flag of 'Allow Reconciliation' is on
4. Go to Taxes > 15% sales > set 'Tax Exigibility' as Based on Payment and 'Cash Basis Transition Account' always as 201000 Current Liabilities
5. Go to Currencies and set a new currency like MXN inserting tax rates as:
	1. 1 july 2026: 20$
	2. 15 july 2026: 15$
6. Create a new invoice with price 100 and 15% tax, set MXN as currency for the journal, set the date as 1 july and confirm it
7. Click on 'Credit Note', then 'Reverse and Create Invoice' and confirm it
8. go back to the invoice and see that after the total amount there is a new line 'Reversed on...'
9. After that line there should also be the line with the Exchange Difference since the tax rates for MXN currency were different at the moment of the invoice and at the moment of the credit note. This is only created by resetting to draft the credit note and confirm it again.

### Cause of the issue:
In the account.move.reversal wizard, when is_modify = True (Reverse and Create), the system triggers _reverse_moves with cancel=True. At the end of the _reverse_moves method, the newly created reverse moves are automatically posted and reconciled. However, this automatic posting is executed with move_reverse_cancel=True injected into the context: reverse_moves.with_context(move_reverse_cancel=cancel)._post(soft=False). When the reconciliation engine (_reconcile_plan_with_sync and _create_exchange_difference_moves) detects this specific context key, it intentionally bypasses the creation of both the exchange difference P&L moves and the cash basis entries, treating the reversal as a pure administrative cancellation rather than a financial operation with currency fluctuations.

### Reason to introduce the fix:
To ensure financial accuracy and compliance, especially when cash basis and multi-currency are involved, a reversal on a different date must reflect the actual exchange rate fluctuations and properly trigger cash basis rules. By removing the move_reverse_cancel context injection during the automatic posting of the reverse moves, we allow the native reconciliation engine to evaluate the newly computed balance (based on the credit note's date) against the original invoice. This ensures that exchange differences and cash basis journal entries are automatically and accurately generated on the first attempt.

opw-6399867

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

Forward-Port-Of: odoo/odoo#283306
Forward-Port-Of: odoo/odoo#281498

## Steps to reproduce:

- Create another warehouse
- Create a product with a variant, like Color, values black and white
- Track the product, add a qty on hand of 50 on the black product
- Go to the sales app, make a quotation of 50 for the black product
- Confirm the quotation
- Go to the PoS, click on the product, check the available qty in the popup
- It is still 50, even though the forecasted is correct at 0

## Why the fix:

Having the actual free qty was added in this commit 682bc82 to be able to check the qty that was really free instead of the available qty. This means that we subtract the reserved_qty from the qty_available to get the free_qty.

The variant popup was forgotten in this commit, so it was still displaying the qty_available. This is why there was a difference in the qty if we press the product normally or if we long press it, because the variant popup was forgotten in said commit.

opw-6382845

Forward-Port-Of: odoo/odoo#283659
Forward-Port-Of: odoo/odoo#280330

### Steps to reproduce:

- Enable Multi-Steps Routes, subcontracting and unarchive the MTO route
- Create 3 products: Final Product (FP), Subcontracted Component (SB), Component (COMP) and put SB in MTO
- Create a BOM for FP: 1 x SB
- Create a subcontracted BOM for SB: 1 x COMP
- Create and confirm an MO for 1 unit of FP
> This generates a subcontracted MO for 1 unit of SB
- Confrim the subcontracted PO and go back to the MO of FP
#### > The component move forecast appears "Available" even if the SB unit is neither received nor 'pre-reserved' (the quantity of the move raw is still 0).

### Cause of the issue:

The `forecast_widget` displays an available status in case the demand of the move is expected to be fulfilled and there is no `forecastExpectedDate`:
https://github.com/odoo/odoo/blob/a46cdcd9d0b575eb668ed738565637f346bbdf7b/addons/stock/static/src/widgets/forecast_widget.xml#L1-L19 https://github.com/odoo/odoo/blob/4fbd88ad3ac2d92b47b024b96f1c40ed4b3f97e3/addons/stock/static/src/widgets/forecast_widget.js#L15-L26 Now, the issue is that this `forecastExpectedDate` is currently unreliable in this use case as the `forecast_expected_date` of the SB component move is incorrectly computed to be False rather than matching its subcontracted receipt counter part. To be more precise, the `forecast_expected_date` is computed based on the report lines: https://github.com/odoo/odoo/blob/8b8b99e371fcf214b9c55fb2fbfca20f2ee66f53/addons/stock/models/stock_move.py#L579-L581 https://github.com/odoo/odoo/blob/8b8b99e371fcf214b9c55fb2fbfca20f2ee66f53/addons/stock/models/stock_move.py#L2701 The component move is an out move of SB from Stock to Production and is linked to the finished subcontracted move of SB from Production to Subcontracting. In particular, this finished subcontracted move (which is assigned) contributes to the 'reserved' out qties on the get go and leads to an already reserved out quantity of 1.0 even thought the move is purely external and linked to the subcontractor process: https://github.com/odoo/odoo/blob/ef89bc530ffae93a553003559ca9078b7a9d0653/addons/stock/report/stock_forecasted.py#L241-L268
In turn, the `demand_out` matched its `reserved_out` (even thought this reserved_out should be 0) so that no `in_transit` move is provided to provide an `expected_date`:
https://github.com/odoo/odoo/blob/ef89bc530ffae93a553003559ca9078b7a9d0653/addons/stock/report/stock_forecasted.py#L426-L435

opw-6445209

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

Forward-Port-Of: odoo/odoo#283177

Problem:
When using horizontal groups in Aged Receivables / Aged Payables reports, the amounts shown in the Older periods are incorrect.

Steps to reproduce:
1. Activate debug mode
2. Go to Accounting > Configuration > Horizontal Groups
3. Add a new horizontal group that results in at least 2 groups
4. Go to Accounting > Reporting > Aged Receivables / Aged Payables
5. Apply the horizontal group created
6. Notice how the amount in the Older period is incorrect, different from before applying the horizontal group. (It may be coincidentally correct, you can check by applying different aging intervals until you find one that shows the issue)

Cause:
The periods were not correctly calculated. The number of periods was calculated based on the number of period columns, without taking into account the number of column groups. When using horizontal groups, period columns are duplicated for each group that exists after applying the horziontal group. This is not considered when calculating the number of periods, which results in calculating too many periods and therefore having incorrect durations for each period.

opw-6374639

Forward-Port-Of: odoo/enterprise#127570

Since `company_id` on `worksheet.template` changed due to this a973d7d from a Many2many to a Many2one field.

For example, in v17, a single worksheet template linked to 3 companies via the m2m field was returned as 1 record when opening Design Template. After the upgrade in v18, company_id became m2o, and the same data is split into 3 separate records (one per company).

When trying to add a customization via Studio, the search [fetches](https://github.com/odoo/enterprise/blob/18.0/worksheet/controllers/main.py#L12) records based on the model set on the worksheet. In the new version, Studio
[creates](https://github.com/odoo/enterprise/blob/18.0/worksheet/models/worksheet_template.py#L112)
 a new model, but for existing records the
model is the same across the 3 worksheet records tied to the same template. This causes the search to match all 3 records and raise a SingletonError.

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/industry_fsm_report/controllers/main.py", line 9, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/worksheet/controllers/main.py", line 17, in edit_view
    worksheet_template_to_change._generate_qweb_report_template()
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 490, in _generate_qweb_report_template
    new_arch = self._get_qweb_arch(worksheet_template.model_id, report_name, form_view_id)
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 460, in _get_qweb_arch
    if 'name' in row_node.attrib and row_node.attrib['name'] not in self._get_qweb_arch_omitted_fields() and row_node.attrib['name'] in form_view_fields:
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 378, in _get_qweb_arch_omitted_fields
    'x_%s_id' % self.res_model.replace('.', '_'), 'x_name',  # redundant
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1657, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: worksheet.template(3, 14, 18)
```

OPW: 6389190

Forward-Port-Of: odoo/enterprise#126773

Steps to reproduce
---
1. Create a quality control point on the Receipts operation type with Control per set to Operation.
2. Confirm a receipt of 2 units of the product: one pending operation quality check is created.
3. In the Barcode app, receive 1 unit and go back to the transfer with the back button.
4. The pending operation quality check is gone.

Issue
---
Going back from the Barcode app calls `post_barcode_process`, which on a partial reception splits the picked move into a done move and a remaining move, then merges the transient duplicate back with `_merge_moves`. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/stock_barcode/models/stock_move.py#L57-L60

`_merge_moves` cancels that transient duplicate through `_action_cancel` before unlinking it. https://github.com/odoo/odoo/blob/8f3100ca597559945cc42d9ef9517edbb40a900b/addons/stock/models/stock_move.py#L1400-L1401

The `quality_control` override of `_action_cancel`, picks the pending checks to drop from `is_product_canceled`, a `defaultdict(lambda: True)` keyed by `(picking, product_id)`. An operation check has no `product_id`, so its key is never computed by the loop and reads back the `True` default, so it is deleted even though the transfer still has a live move. Since an operation check covers the whole transfer, it must be dropped only when every move of its picking is cancelled. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/quality_control/models/stock_move.py#L68-L76

opw-6439179

Forward-Port-Of: odoo/enterprise#128767
Forward-Port-Of: odoo/enterprise#127427