Steps to reproduce:
-------------------
1. Set up a POS with a currency different from the company currency (e.g. company in USD, POS in SSP).
2. Create a USD pricelist with a surcharge rule (e.g. +10 USD on list_price).
3. Create an SSP pricelist that references the USD pricelist as its base (base = "pricelist"), with an additional discount rule.
4. Assign the SSP pricelist to the POS and add a product.

-> The displayed price ignores the currency conversion between the two pricelists: surcharges/discounts are applied as if both pricelists share the same currency.

What's happening:
-----------------
The POS pre-converts product prices from company currency to POS currency in `_load_pos_data_read`. However, `getPrice` in JS never converts between the POS currency and the pricelist's own currency before applying the rule's formula (surcharge, discount, etc.).

The fix:
--------
In `getPrice`, convert the price from POS currency to pricelist currency before applying the rule, then convert back afterward.

Note that we have changed the loading order of the models for `pos_self_order`, such as 'res.currency' records are loaded after 'product.pricelist' ones, because now the loaded currencies depend on the loaded pricelists.

opw-6013513

Forward-Port-Of: odoo/odoo#260195
Forward-Port-Of: odoo/odoo#255357

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