Issue:
When creating a payment with an early payment discount, on an invoice using a cash rounding with a strategy of “Modify tax amount”, the early payment discount lines on the payment journal entry will be far off from the correct amount

Steps to reproduce:
1. Create a sales tax for 8.1%
2. Create a cash rounding record for 0.05 as the rounding precision, “Modify tax amount” as the rounding strategy, and “Nearest” as the rounding method
3. Create a payment term with early payment discount of 2% if paid within 18 days. And reduced tax on early payment. With a due term of 100% 30 days after the invoice date
4. Create an invoice on 1/1 with a subtotal of 339.60 and the tax of 8.1% and add the cash rounding method and payment term created earlier
5. Create a payment for it 9 days later on 1/10 for the full amount after the early payment discount is applied

Cause:
tax_amounts is grabbing the amount for a certain tax from the last line on the invoice with the same tax_repartition_line_id. Usually there is only one tax line representing a certain tax on an invoice. However, when a cash rounding is applied to the invoice with a strategy of “Modify tax amount”, the cash rounding line that is created will also have the same tax_repartition_line_id. In that case, it will grab the amount on the cash rounding line instead of adding the first tax amount with the cash rounding line amount

Solution:
In tax_amounts, add to the accumulating value if a tax repartition line id already exists as a key otherwise, insert it into tax_amounts

opw-5998497

Forward-Port-Of: odoo/odoo#259025

Steps to reproduce
1. Open any kanban view declaring a <progressbar> (e.g. Project > Tasks, or Field Service > My Tasks).
2. Group by a date or datetime field with a granularity (e.g. Creation Date: Year, planned_date_begin:day).
3. Have records spread across several groups with different state values (done, in progress, canceled, ...).
4. Observe the colored progress bar at the top of each column.

Issue
Every column's progress bar renders as a uniform grey block regardless of the actual state distribution of its records. The effect is visible only when grouping by a date/datetime field; grouping by stage or assignees still works.

The kanban relies on two separate RPCs whose keys must match: formatted_read_group (used by web_read_group) returns the columns the client stores, and the client uses each column's formatted groupby value as the lookup key; read_progress_bar returns a dict mapping that same key to per-state counts.

For a datetime group by with a time granularity,
formatted_read_group goes through _web_read_group_groupby_formatter, which localizes the naive timestamp in the user's timezone and then converts it to UTC before strftime, see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/models/models.py#L698-L726. On the client, serializeDateTime also formats in UTC, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/core/l10n/dates.js#L455-L462, so group.serverValue is the UTC-shifted string the server sent, e.g. "2025-01-01 08:00:00" for a Pacific-tz user on a 2025-year group.

read_progress_bar called _read_group directly, which returns the raw naive datetime out of date_trunc, see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/odoo/orm/models.py#L1764, so its dict was keyed by str(datetime(2025, 1, 1, 0, 0)) = "2025-01-01 00:00:00". The UTC-formatted key the client looks up in _pbCounts[groupValue], see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L69, never matched, per-state counts stayed at zero, and the synthetic "Other" bucket with color "200" (grey) absorbed the whole group.count, see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L88, hence the uniform grey bar.

Non-date groupbys (many2one, selection, boolean) are unaffected because their keys are scalar ids / selection codes that round-trip identically on both sides. The "None" column also works because both sides emit the literal string "False".

The regression was introduced by d5a6e97abab04282c7a69093cd790b539a958241 when read_progress_bar was switched from self.read_group(...), whose output was pre-formatted the same way the client received it, to self._read_group(...)

Solution
Route read_progress_bar through formatted_read_group, the same method web_read_group uses to build groups for the client. Both sides now run through _web_read_group_groupby_formatter, so the keys are produced by the same code path and match by construction for every field type, including date/datetime granularities.

formatted_read_group wraps relational and date/datetime groupby values as (id, display_name) / (utc_str, label) tuples, so the adapt helper unwraps the first element to restore the scalar key shape the result dict expects.

opw-6148736

Forward-Port-Of: odoo/odoo#261024

__

## Short functional explanation of the error
When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours.

## Reproduction Steps
1. Create an employee with a flexible schedule and with Work Entry Source set at Planning.
2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it.
3. Click on the Reporting tab > Planning / Attendance Analysis.

### Expected behavior
The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot.

### Unexpected behavior
The total for this Month for this employee under the Planned Time field is equal to 16 hours.

## Origin of the issue
This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here:
https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated.

__
opw-6146052

Forward-Port-Of: odoo/enterprise#117128
Forward-Port-Of: odoo/enterprise#115447

Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#264235
Forward-Port-Of: odoo/odoo#262722

**Problem:**
The "Custom Dates" and "Specific Date" comparison options are missing from the Comparison dropdown in accounting reports.

**Steps to reproduce:**
1. Go to Accounting > Reporting > Profit & Loss
2. Click the Comparison dropdown
3. Only "No Comparison", "Previous Period", and "Same Period Last Year" are visible — "Custom Dates" is missing

**Current behavior:**
Custom date comparison options are not rendered.

**Expected behavior:**
"Custom Dates" (for range reports) and "Specific Date" (for single date reports) should appear in the Comparison dropdown.

**Cause of the issue:**
The date filter refactor (40484f985f5) restructured how the date mode is stored in options. Previously, `options.date.mode` held 'range' or 'single'. After the refactor, this key no longer exists — the mode is now stored as a boolean in `options.filter_date.range_mode`.

The comparison filter template still checks
`controller.cachedFilterOptions.date.mode`, which is now undefined, so both the range and single conditions always evaluate to false and the custom comparison options are never rendered.

**Fix:**
The comparison template was the only consumer not updated during the refactor. Aligning it to the new data path restores the options without any behavioral change.

opw-6070402

Forward-Port-Of: odoo/enterprise#113391