## Steps to reproduce

- Create an attribute A, of type always, with 2 values, one should have an extra price
- Create an attribute B, of type never, with 2 values
- Create a product that has both those attributes
- Create a combo with that product with both values for A
- Go to the PoS and order that combo with the value that has an extra price for A
- The extra price is added

## Why the fix:

For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo.

As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page.

It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always".

The variants are then considered as different products, as they should in this case.

If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it.

We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 

We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same.

opw-6262431

Forward-Port-Of: odoo/odoo#270894
Forward-Port-Of: odoo/odoo#268567

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#120873
Forward-Port-Of: odoo/enterprise#115446

**Steps to reproduce:**
- make sure your main company (company 1)
has dollars as its main currency
- create second company (company 2) and a 
warehouse in this second company
- set euro has the main currency in the company 2

From company 1:
-  set an exchange rate 
of 1$ = 0.5 eur on the euro currency
- create a storable product with a cost of 10$
and an on-hand quantity of 1

From company 2: 
- set the cost to 10 eur and set an on-hand
quantity of 1

with both company selected and company 1 
as the main company selected: 
- open the stock view and look for your product

**Current behavior:**
the total value is 20$

**Expected behavior:**
with conversion rate, it should be 
30$

**Cause of the issue:**
when computing the total value 
we do not apply a conversion rate from 
the value of the company to the main 
company selected
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/stock_account/models/product.py#L273

opw-6280108

Forward-Port-Of: odoo/odoo#270575

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

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

Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
    - opA: no blocker
    - opB: blocked by opA
    - opC: blocked by opA
    - opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan

Problem:
opA was scheduled after opB, violating the dependency.

`_plan_workorders` starts planning from the "leaf" workorders (those
with no dependents). Given the structure above, the initial set is
[opB, opD]. Processing opB first correctly plans opA then opB. But
processing opD triggers a recursive chain opD→opC→opA which calls
`action_unplan(opA)` and replans it from scratch. By then, opB already
occupies the workcenter slot that opA originally held, so opA ends up
scheduled after opB.

Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.

opw-6299179