Issue:
Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated

Steps to reproduce:
1. Create and confirm a monthly recurring invoice
2. Create a payment for the invoice
3. Create a batch payment and add the payment created in step 2 then validate it
4. Create a bank statement line and reconcile it with the batch payment created in step 3
5. Unreconcile the payment from the invoice from the invoice form view
6. Notice that a draft invoice for the next month’s recurring invoice is created

Cause:
When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period

Solution:
Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line”

opw-6158881

Forward-Port-Of: odoo/odoo#263991

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

When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date.

OPW-6099192

---

### Test result without fix

```
2026-04-23 06:30:34,016 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: Starting TestStockValuation.test_archived_location_valuation ... 
2026-04-23 06:30:34,255 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: ====================================================================== 
2026-04-23 06:30:34,255 10516 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_archived_location_valuation
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3326, in test_archived_location_valuation
    self.assertEqual(self.product_avco.with_context(to_date=date_1).avg_cost, 10)
AssertionError: 20.0 != 10
 ```

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

Forward-Port-Of: odoo/odoo#260922

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117111
Forward-Port-Of: odoo/enterprise#115046