Since the Accounting Returns refactor https://github.com/odoo/enterprise/pull/81569 the “Returns” button and the Return-Period date mode only appear when the current `account.report` carries at least one return type (i.e., `self.return_type_ids` is non-empty). Localization modules (e.g., PE) attach `account.return.type` to the filing (root) VAT report, while ledger/variant reports (e.g., VAT Report (RCE Purchase 8.5) (PE)) are presentation variants and usually do not repeat that configuration.

As a result, opening a variant report yields:
No Returns button, because _init_options_buttons() checks only `self.return_type_ids`. No Return Period chip and wrong/no return-period boundaries, because the date initializers also check/use only `self.return_type_ids`. Even if the button is shown by a downstream customization, `action_open_returns() would still open an empty list because it filters on `self.return_type_ids.ids`.

Why the issue happens:
Variant reports (like RCE 8.5) have `self.root_report_id` pointing to their root VAT report, which does carry `return_type_ids`. But the in odoo we  checks/uses only the current report’s`return_type_ids`, which is empty on variants. Hence: missing Returns button, missing Return Period, and wrong/empty return filtering.

Fix:
Adopt the reporting engine’s existing “inherit from root when on a variant” pattern and its already used elsewhere for `variants_source_id`, custom handlers ...

Introduce a tiny helper: Prefer explicit types on the current report if present; otherwise fall back to the root’s types. Replace direct uses of self.return_type_ids by the effective types in: _init_options_buttons: show Returns on variants too. _init_options_return_periodicity: enable Return Period on variants when the root has exactly one type. _init_options_date(return-period branch):  compute correct boundaries from effective types. _get_shifted_dates_period(return-period branch): shift using effective types. _get_date_bounds_info(..., 'previous_return_period'): validate count and compute previous period from effective types. action_open_returns: filter the list view by the types of variants if present or the root  instead if the variant’s empty.

Before this commit:
On VAT Report (RCE Purchase 8.5) (PE): no Returns button is shown when you are in variant.

After this commit:
Returns button appears.
Return Period mode works
Open Returns action lists the correct returns (filtered by the effective type).

Steps to reproduce:
Install PE_reporting module
make sure dev move is on
Accounting -> Reporting -> tax reports
Click on reports and switch from `Report: Group by: Account > Tax` to `RCE Purchase 8.4` Return Button is not there any more :(

[opw-4973204](https://www.odoo.com/odoo/my-tasks/4973204)

### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#253948
Forward-Port-Of: odoo/odoo#253406

project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company.

Following examples earlier in the function, call `.with_company` while accessing project_template_id.

Steps to reproduce:
1. Install Sales and Project
2. Create second company
3. Create Customer with portal access, under created company
4. Create service product with different projects for each company
5. Create sales order with customer and service product, send to customer
6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console

Ticket: opw-6082772

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#260387