Steps to produce:
---
- Install website_sale module.
- Enable `Comparison Price` from settings.
- Create a product with sales price = 25 and compare price = 25.
- Go to the shop page and search for the product.

Issue:
---
- The strikethrough appears on the compare price (25) even when the compare price equals the sales price.
- The strikethrough should only appear when the compare price is strictly greater than the sales price.

Root cause:
---
- In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal.

Solution:
---
- Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2].

Before:
---
<img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" />

After:
---
<img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" />


[1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834
[2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346

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

Forward-Port-Of: odoo/odoo#265004
Forward-Port-Of: odoo/odoo#262434

**Steps to reproduce:**
1. Install Time Off
2. Go to Accrual Plans and create a new plan with a milestone
3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday)
4. Save and check the displayed weekday in the accrual plan level

**Issue:**
The displayed weekday is incorrect (e.g., shows Monday instead of Tuesday).

**Cause:**
Previously, the weekday value was directly displayed using: https://github.com/odoo/odoo/blob/b40184ab371f7a4708621ecf7f25b4e2daaae38d/addons/hr_holidays/views/hr_leave_accrual_views.xml#L212-L214 so no conversion was involved.

Now, the value is processed using Luxon. However, the week_day field stores values from 0 (Monday) to 6 (Sunday), while Luxon expects ISO weekday numbers from 1 (Monday) to 7 (Sunday). This mismatch causes an off-by-one error during conversion.
https://github.com/odoo/odoo/blob/1b3d0a3c2f794324f8b230a9ae19f097454e3bdd/addons/hr_holidays/models/hr_leave_accrual_plan_level.py#L54-L62

**Solution:**
Adjust the value before passing it to Luxon by adding +1 to match ISO format.

opw-6112614




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

Forward-Port-Of: odoo/odoo#259054

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#117115
Forward-Port-Of: odoo/enterprise#111304

# How to reproduce
- Create 2 MO's A & B, both having the same product_id & bom_id
- Split MO A into two MO's A1 & A2
- Merge MO's A1 & B

# The issue
MO A2 no longer has a production group (visible via Studio).
If the user tries to partially produce the MO and create a backorder, a traceback popup appears with :

"ValueError: max() iterable argument is empty"

# Cause
The traceback is triggered because we use the `max()` function on `self.production_group_id.production_ids` when creating the backorder, but `production_ids` is an empty recordset since `production_group_id` is also empty.

https://github.com/odoo/odoo/blob/0d8eaeeb971f2f670aebb1b72ed03f4a2d5e0105/addons/mrp/models/mrp_production.py#L1936

The production group is empty because when merging two MO's we delete it without paying attention to other remaining links.

https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/mrp/models/mrp_production.py#L2555

Note : the production groups were introduced by this commit (https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a)

# Proposed solution
When merging, we unlink the original MO's from their production group.
Then, we check every altered production group : if they are not linked to any MO anymore, we delete them.

opw-6055376

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

Forward-Port-Of: odoo/odoo#256600

### Description of the issue/feature this PR addresses: 
**Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400 Client Error: Bad Request for url: https://api.ksef.mf.gov.pl/v2/auth/xades-signature"_ This is due to Odoo not handling different `SubjectIdentifierType`

**Solution**: Implement a try/except block to safely check for the NIP in the certificate's subject string, defaulting the identifier type to `certificateFingerprint` when the NIP is missing or a ValueError is caught.

### Current behavior before PR:
The `SubjectIdentifierType` is hardcoded as `certificateSubject`, and does not handle `certificateFingerprint` at all. This causes there to be an error when trying to authenticate with the KSeF server using XAdES signature.

### Desired behavior after PR is merged:

The sign_authentication_challenge method will now safely evaluate the subject string. It assigns `certificateSubject` only if the NIP is verified to be in the subject string. If the NIP is absent or a ValueError occurs during parsing, the system safely falls back to using `certificateFingerprint`. This prevents tracebacks and ensures the correct XML payload is sent to the KSeF server.

Ticket [link](https://www.odoo.com/odoo/project.task/6125243)
opw-6125243

Forward-Port-Of: odoo/odoo#264851

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

The business premises label on Croatian invoices can legitimately contain alphanumeric characters (e.g., "v1"), as noted in the field's tooltip.

However, the regex pattern inside `_get_l10n_hr_fiscalization_number` used to extract the sequence parts strictly expected digits (`\d+`) for the premises label segment. Because of this, if an invoice was generated with an alphanumeric sequence like `INV-2026-0001/v1/1`, the regex failed to match and returned `False`, leading to a traceback when the system attempted to process the fiscalization number.

This commit updates the regex to correctly accept alphanumeric characters for the premises label, ensuring the sequence parses successfully.

opw-6129009

### Steps to reproduce:

- Settings > Users & Companies > Companies > New > set Address country to Croatia
- Select the newly created Croatian company
- Apps > Activate l10n_hr_edi module
- Accounting > Configuration > Accounting > Journals > click Sales journal > change “Business premises label” to “v1”
- Contacts > New > set Address country to Croatia
- Accounting > Customers > Invoices > New > select the newly created contact and choose any product > Confirm

### Current behavior before PR:

Traceback error when attempting to confirm an invoice when both the company and the customer have their country code set to 'HR'. This is because `_get_l10n_hr_fiscalization_number` does not accept alphabet characters in the premises label section of the regex.

### Desired behavior after PR is merged:

- No traceback error when confirming the invoice
- `_get_l10n_hr_fiscalization_number` correctly parses the fiscalization number

Forward-Port-Of: odoo/odoo#263650

Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions.

**Steps to Reproduce:**
 - Install `l10n_au_hr_payroll_account` with demo data.
 - Switch to an `Australian` company.
 - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`.
 - Open an existing record or create a new one.
 - Remove the `Source Entity Id Type` value and click anywhere.

`ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id`

After [change] in the selection field behavior, when the user removes the Source Entity Id 
Type, the compute method is triggered to compute the Source Entity ID. However, the 
condition in the compute method is not match, so no value is assigned. As a result, 
the method fails and raises an error.

This commit ensures that if the condition is not match, the Source Entity ID is explicitly 
set to False.

[1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

Forward-Port-Of: odoo/enterprise#115466

When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.

`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.

The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.

The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.

Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown

=> Archived teams appear in the dropdown

Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801

Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117073

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#116930
Forward-Port-Of: odoo/enterprise#115451

The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10`

This shifts the max aml.id 40 bits to the left.

Example:
Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number.

1 << 20 = 1048576
1048576 | 1 = 1048577
1048577 << 10 = 1099512676352
1099512676352 | 1 = 1099512676353
1099512676353 << 10 = 1152922604119523328

With this format, the highest guaranteed AML ID this query can handle is under 838,861.

The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id`

|  | AML Max | RULES.ID Max |RULES.USER_ID Max|
| --------------------- | ------ | ------ |  ------ | 
| Before | 838,861  | 1,048,576 | 1,024 |
| After | 858,993,459 |1,048,576 | 1,024|

opw-6124026

Forward-Port-Of: odoo/enterprise#114711

__

## Short functional explanation of the error
When checking the dashboard on a project we created with a yearly subscription, the values shown are incorrect.

## Reproduction Steps
1. Create a new product. Check the Subscription field and set the Product type as Service. On the Create on Order field, set Project & Task. Then, in the Recurring Price tab, add a Monthly plan with price 50 and yearly plan with price 40.
2. Create a new Quotation. Set a customer and add the product you just created in an Order line. Set the Quantity to 100 and set the recurring plan as Yearly. You'll see the amount be at 4000, and the total amount at 4600 with taxes. Click on Confirm.
3. Create an invoice and confirm it.
4. Click on the Project smart button. Then, on the top right, click on the view menu > Top Menu. Select Dashboard and click on it.

### Expected behavior
On the dashboard, we should see the Revenues under Profitability at 4000. To invoice should be left at 0 and Invoiced should be at
4000. Expected should be at 4000.

### Unexpected behavior
On the dashboard, To Invoice is at 333, and Expected is at 4333. This corresponds to our invoice + 4000/12 -> monthly recurring plan, with the price of the yearly plan!

## Origin of the issue
We always add the `recurring_monthly` value when showing the profitability, no matter the recurring plan:
https://github.com/odoo/enterprise/blob/cdc0d5d57f6b27a6bb5e451d48bdbef4e3dde5cb/project_sale_subscription/models/project_project.py#L86
We should only add the `recurring_monthly` value for as many monthly
subscriptions we have, not for *all* the subscriptions.
__
opw-5916688

Forward-Port-Of: odoo/enterprise#113918

Steps to reproduce:
===================
1. Go to the shop page and use the rental date picker to select a start and end date with hours.
2. Find a rental product configured with "Days" pricing.
3. Add to card directly from the product card
4. Add a rental product from product image that has date type value date
5. Go to that product details page.
6. Click add to cart

-> Invalid operation, You cannot mix different rental periods...

Cause:
======
When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added.

However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing).

This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page).

Solution:
=========
The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist.

opw-5450576

Forward-Port-Of: odoo/enterprise#103373

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#117490
Forward-Port-Of: odoo/enterprise#115285