Steps to reproduce:
- Create a storable product "P1"
- Update on-hand quantity to 2 units
- Create a delivery with 2 units of P1 and keep it in draft state

Problem:
The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move.

Explication:
For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty`

In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty`

So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available.

https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31

Solution:
When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available.

opw-5159142

Forward-Port-Of: odoo/odoo#260489
Forward-Port-Of: odoo/odoo#257354

When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times.

Steps to reproduce:
-------------------
* Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule"
* Create three products : final, semi, component
   - final: mtso, manufacture
   - semi: mtso, manufacture
   - component: mtso, buy, on hand quantity to 4
* Create a bom for final:
   - 10 components
   - 1 semi
* Create a bom for semi:
  - 10 components
* Create and confirm a MO for 1 "final"
-> Issue the purchase order is only for 12 components and not 16.

Observation:
-------------
When confirming our MO, it will create a manufacture procurement for the products.
The procurement will recursively create procurements and stock moves for each of its components.
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571
Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity:
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663
And each procurement, if it is of the manufacture type, will create corresponding procurements for their components.

Once all the procurements and stock moves have been created, the stock move will confirmed and assigned.
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629


-> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels.

opw-5514788

Forward-Port-Of: odoo/odoo#253958

## Overview
Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS data loading flow.

## Steps to Reproduce
1. Install `pos_blackbox_be`
2. Open POS  
3. Access the Mobile Menu (QR code) or Self-Ordering page  

## Current Behavior
- A traceback is raised  
- The interface does not load  

## Root Cause
The method `_load_pos_self_data_fields` returns the field:
iface_fiscal_data_module

However, from SaaS-19.1 this field was renamed to:
iot_fdm_be_id

This mismatch causes the POS self-ordering data loading to fail.

## Fix
Updated the returned field to match the new field name.

# Before
return fields + ['iface_fiscal_data_module']

# After
return fields + ['iot_fdm_be_id']

## Impact
- Restores proper loading of Mobile Menu (QR ordering)  
- Fixes Self-Ordering interface crash

opw-6044883  

## Reproduction Video
https://drive.google.com/file/d/1R5TYVIXvtts12YLF5iB4GKZirMZePoGr/view?usp=sharing

Forward-Port-Of: odoo/enterprise#114357

**Problem:**
Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match).

**Steps to reproduce:**
1. Create two websites with no domain set
2. Change their sequence order via the handle widget in the backend
3. Open an incognito window
4. The default website shown is still the old one

**Current behavior:**
The default website does not change after reordering.

**Expected behavior:**
The website with the lowest sequence should be served as the default.

**Cause of the issue:**
Commit d6f4af2790a0 replaced `models.Model` with `models.CachedModel` and removed the blanket `self.env.registry.clear_cache()` from the top of `write()`. CachedModel only auto-clears caches for fields listed in `_cached_data_fields`, but `sequence` is not in that list. As a result, `_get_current_website_id` (decorated with `@tools.ormcache`) keeps returning the stale cached website ID after a sequence change.

https://github.com/odoo/odoo/commit/d6f4af2790a0abacba6e616b00d999eddc30edc9#diff-5e92e473fa4d3da6db7ef727fb217dad51ef6c2383913edca73fe040a23e82c2L339-L341


**Fix:**
Restoring `clear_cache()` scoped to the existing sequence/company_id check ensures the ormcache is invalidated only when relevant fields change, rather than on every write as before.

opw-6102426

Forward-Port-Of: odoo/odoo#257913

**Steps to reproduce:**
* Install modules: *mrp*, *purchase*, *sale_management*.
* Go to *Settings* and enable:
  * *Multi-Step Routes*
  * *Replenish on Order (MTO)*
  * *Dropshipping*
* Create a *Dropship* product:
  * Set route to *Dropship*.
  * Add a vendor under the *Purchase* tab.
* Create an *MTO* product:
  * Set route to *Replenish on Order (MTO)*.
  * Configure a *Bill of Materials (BoM)*.
* Create a *Sales Order*:
  * Add both products.
  * Confirm the order.
* Open the Sales Order:
  * Observe smart buttons for *Delivery*, *Purchase*, and *Manufacturing*.
* Open the linked *Purchase Order* and *Manufacturing Order*.

**Observed behavior:**
* The *Purchase Order* shows a smart button linking to a *Manufacturing Order*.
* The *Manufacturing Order* shows a smart button linking to a *Purchase Order*, even when unrelated.

**Expected behavior:**
* The *Purchase Order* should only show a smart button linking to the *Sales Order*.
* The *Manufacturing Order* should only show a smart button linking to the *Sales Order*.
* No cross-link between unrelated PO and MO should be displayed.

**Cause:**
* The SO pushes the `stock.reference` into procurement values: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/sale_stock/models/sale_order_line.py#L289
* The same reference is propagated to:
  * Purchase Orders: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/purchase_stock/models/stock_rule.py#L355
  * Manufacturing Orders: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/mrp/models/stock_rule.py#L184

* Opening the *Purchase Order* form triggers `_compute_mrp_production_count`.
* This compute calls `_get_mrp_productions()`: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/purchase_mrp/models/purchase.py#L21
* That method returns `self.reference_ids.production_ids`.
* Since the MO shares the same sale reference, the PO incorrectly fetches that MO and shows the *Manufacturing* smart button.

* Similarly, opening the *Manufacturing Order* form triggers `_compute_purchase_order_count`.
* This compute calls `_get_purchase_orders()`, which returns `self.reference_ids.purchase_ids`.
* Since the dropship PO shares the same sale reference, the MO incorrectly fetches that PO and shows the *Purchase* smart button.

**Fix:**
* Stop relying on shared `reference_ids` to compute links.
* Instead, follow the actual stock and procurement chain:
  * For *MO → PO*:
    * Use raw material moves to find related purchase lines: `self.move_raw_ids.created_purchase_line_ids.order_id | self.move_raw_ids.purchase_line_id.order_id`
  * For *PO → MO*:
    * Use stock move destinations to identify consuming productions.
* This ensures:
  * MOs link only to POs supplying their raw materials.
  * POs link only to MOs they actually replenish.
  * Unrelated documents sharing the same sale reference remain isolated.

---
opw-6008943

---

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#254292