Steps to produce:
---
- Install `website_sale` module.
- Enable ` Units of Measure & Packagings `and `Comparison Price` features from settings.
- Create product > set sales price as 5 and Compare to Price as 12.
- From the sales tab, under Upsell & Cross-Sell > set Packagings as pack of 6.
- Go to the shop page on eCommerce, and add your product via the shop page (this should open the product configurator).
- Change the UOM from the radio.

Issue:
---
- Changing the UOM doesn't change the strikethrough price.

Root cause:
---
- At [1], The `_get_strikethrough_price` method was not receiving the selected uom parameter, causing it to compute the compare_list_price based on the product's base uom instead of the user-selected uom.

Solution:
---
- Pass `uom` parameter from `_get_basic_product_information` to `_get_strikethrough_price`
- Apply uom conversion to compare_list_price when the selected uom differs from the product's base uom.
- Also fix pricelist base price calculation to use the selected uom.
- Update the JS logic to refresh the strikethrough price when the uom
  changes.

[1]https://github.com/odoo/odoo/blob/bfcb22256226ae056e934e2f9e498e8cea4d2f63/addons/website_sale/controllers/product_configurator.py#L101-L154

Before:
---
<img width="974" height="321" alt="image" src="https://github.com/user-attachments/assets/f360d730-bedf-4898-ba22-c47ea8fa1df7" />

After:
---
<img width="977" height="321" alt="image" src="https://github.com/user-attachments/assets/79d66143-959c-4f39-9272-437cb768837e" />


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

Forward-Port-Of: odoo/odoo#263556

### Issue before this commit:
In accrual reports (e.g., "Bill To Receive", "Billed Not Received", "Invoices To Be Issued", and "Invoices Not Delivered"), when grouping the list view by fields such as Vendor, the group header totals for the "Received", "Billed", and "Amount" columns display 0.00 even if the interanl lines of the group are not 0.00.

### Steps to reproduce the issue:
1. Download Purchase Accounting and Sale Accounting
2. Go to one of this pages: Billed Not Received, Bill To Receive, Invoices To Be Issued, and Invoices Not Delivered
3. Ensure the view is in its default grouping (grouped by Vendor or Customer)
4. Observe the group header rows for the Received (or Delivered), Billed (or Invoiced), and Amount columns. They all display 0.00
5. Expand a group that contains records with values greater than zero
6. Observe that the individual records populate correctly, but the aggregated group header row continues to display 0.00.

### Cause of the issue:
The commit ddc1b681656ea8c70f3231cda20b5a58b9ff7dd6 adapted the code to retrieve the new accrual reports but attempted to fetch grouped records using group[0].id as the dictionary key, while the grouped() method actually used the recordset object as the key. This mismatch caused the dictionary lookup to fail, resulting in 0.00 sums. https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/account_accountant/models/analytic_mixin.py#L40-L48

### Reason to introduce the fix:
This fix restores the core analytical utility of the accrual reports, which are crucial for accountants during period-end closings to evaluate totals at a glance.

opw-6232273

Forward-Port-Of: odoo/enterprise#118399

### Issue
When setting the partial deductibility percentage to 99% on a vendor bill line, the system incorrectly treats it as 100% deductible and completely ignores the non-deductible part

Additionally, changing the deductibility percentage on a line with taxes does not trigger an update of the
non-deductible tax journal items, leaving the private part taxes unchanged

### Cause
In the tax recomputation mechanism, `float_compare` was wrongly configured with `precision_rounding=2` instead of `precision_digits=2` when checking the `deductible_amount` field

This rounding error caused 99.00 to be evaluated as equal to 100.00, skipping the creation of the non-deductible line

Furthermore, `_sync_tax_lines` relies on `get_base_line_tracked_fields` to detect modifications that require a tax recalculation

This tracked field list only included price, quantity, and discount. Modifying the deductibility percentage did not trigger any sync, preventing the non-deductible tax lines from adjusting

### Fix
To fix the synchronization, `deductible_amount` is added to the tracked fields for invoices
This straightforward approach is preferred here for simplicity
However, a more restrictive condition may be needed for example only check it on lines with taxes

### Steps to reproduce
- Install `account`
- Create a Vendor Bill  (Price: 1000$, Taxes: 15%, Professional %: 50)
- Check the Journal Items tab to see the Private Part line at 500$ debit and Private Part (taxes) line at 75$ debit
- Change the Professional % field on the invoice line to 75 Before the fix, the Private Part (taxes) line remains at 75$ debit
- Change the Professional % field on the invoice line to 99 Before the fix, the private part lines completely disappear instead of adapting to 1%

opw-6245909

Forward-Port-Of: odoo/odoo#267427

### Steps to reproduce:

- Enable `Lots & Serial Numbers` and `Packages` in the settings
- Create a product tracked by SN and add SN001 and SN002 to stock
- Create and confirm a delivery for 2 units
- Open the Barcode app and open the delivery
- Scan the product > Scan SN001
- Click `Put in Pack`

### Current behavior:

The created package is not displayed anywhere. Clicking Put in Pack again nests the package into another package without any visible indication to the user.

### Cause of the Issue:

The GroupedLineComponent cannot display neither the source or destination package:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.xml#L4-L21
However, our case the grouped line contains only a single line and prevents the users from viewing the sublines since the `Show Reserved Lots` is disabled on the operation type and only one lot (with additional demand) was scanned:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L75-L77 https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L44-L55

opw-6237834

Forward-Port-Of: odoo/enterprise#119114

The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations:

1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order

2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000.

3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans.

Benchmark (page 1 load):

_prepare_tasks_values (milestone + count, excludes lazy main search):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.294s    | 0.230s   |
| 1,500,000 |      2,000 | 0.511s    | 0.222s   |
| 3,000,000 |     12,000 | 1.129s    | 0.258s   |
| 6,000,000 |     24,000 | 2.388s    | 0.261s   |
| *6,000,000|     24,000 | 2.015s    | 1.976s   |

*6M measured while navigating last page (full count triggered).

Main search query (ORDER BY fix):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.525s    | 0.013s   |
| 1,500,000 |      2,000 | 0.685s    | 0.017s   |
| 3,000,000 |     12,000 | 1.479s    | 0.040s   |
| 6,000,000 |     24,000 | 3.121s    | 0.043s   |
| *6,000,000|     24,000 | 7.562s    | 3.781s   |

Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5
Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b
*6M measured while navigating last page (high offset).

- opw-5478903

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5

Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised

Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
    - Clear the Warehouse field (set it to False)

- Create a purchase order:
    - Set "Deliver To" to the operation type with no warehouse
    - Add any product
    - Try to confirm the PO

Problem:
A traceback is triggered:
```   return self.parent_path.startswith(other_location.parent_path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```

`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False

Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).

opw-6253817

Forward-Port-Of: odoo/odoo#268317

## Issue
When using a prefix containing a time-based placeholder (`%(h24)s`, `%(h12)s`, `%(min)s`, `%(sec)s`) with *Subsequences per date\_range*, the time information are missing and consistently set to 0 when interpolating the prefix.

## Steps to reproduce
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, update the `sale.order` sequence:
    - Prefix: `S/%(y)s/%(month)s/`
    - Suffix: `/%(h24)s/%(min)s/%(sec)s`
    - Tick the *Use subsequences per date_range* checkbox and set a range for the current month
3. Create and confirm a SO
4. **The name of the SO correctly contains the Quotation date in the prefix, but the suffix is set to /00/00/00, even though the quotation date contains time information.**

## Cause
Commit https://github.com/odoo/odoo/commit/f7c330d83cc3 sets the `ir_sequence_date` to a `datetime.date` object in `IrSequence._next`. This leads to the time information missing from the interpolation dict:

https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/addons/base/models/ir_sequence.py#L211-L214

## Fix
The context key `ir_sequence_date` should be set to a `datetime.datetime` object to correctly interpolate the time information in the prefix/suffix of a sequence. To do so, the `tzinfo` needs to be drop for the date to be interpretable by the `fields.Datetime.from_string` method:

https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/orm/fields_temporal.py#L239-L244

The time is not cast to a specific timezone (e.g., UTC) before dropping the tzinfo, as doing so would lead to incoherent time information from the user's perspective. For example, creating a SO at 13:00 in Brussels (UTC+2) would result in  `11` being used as the hour to interpolate the `%(h24)s` placeholder.

opw-6104485

Forward-Port-Of: odoo/odoo#260782