### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Create a non-storable product P
- Go to the barcode app > Operations > Delivery Order > New
- Click on "Add Product" > select P as product > Confirm
#### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there?

### Expected behavior:

Since the product is not storable it should not trigger the dialog

### Cause of the issue:

The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant.

opw-6110655

Forward-Port-Of: odoo/enterprise#114173

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

Steps to reproduce:
-------------------
1. Create a new trial DB with demo data and French localization
2. Archive Marc Demo if you create the DB locally (this happens 
   automatically on Odoo.com trials due to the user seat limit probably)
3. Select the demo company only (unselect the main one)
4. Open Accounting and click the Sales journal from the dashboard

Access Error about reading Marc Demo.
Unarchiving him would work around this issue.

Why the bug
-----------
The sales demo invoices set invoice_user_id to Marc Demo (base.user_demo).
Marc Demo belongs to the main company and can't be read from another
company when archived.

On 19.0 this did not break because the avatar widget only needed
display_name (read with sudo). Commit https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4 added write_date to it
for cache busting, so now the read is real and the rule fails.

The fix
-------
Use base.user_admin instead: it's never archived, so it stays readable
from any company.

opw-6106870

Forward-Port-Of: odoo/odoo#259365

Steps to reproduce:
-------------------
1. Create a new trial DB with demo data and French localization
2. Archive Marc Demo if you create the DB locally (this happens 
   automatically on Odoo.com trials due to the user seat limit probably)
3. Select the demo company only (unselect the main one)
4. Open Accounting and click the Purchases journal from the dashboard

Access Error about reading Marc Demo.
Unarchiving him would work around this issue.

Why the bug
-----------
demo_invoice_deferred and demo_bill_deferred set invoice_user_id to Marc
Demo (base.user_demo). Marc Demo belongs to the main company and can't be
read from another company when archived.

On 19.0 these records only existed in the main company, where Marc Demo
is accessible. Commit 9aed0c0135d7b084dee544c6566fad96c62ec1fd migrated the demo to `template`, so now
they are created in every company.

Still, it only breaks because of commit [3732ca85b03b](https://github.com/odoo/odoo/commit/3732ca85b03b), which added
write_date to the avatar widget for cache busting. Before, the widget
only needed display_name (read with sudo), so the rule was not checked.

The fix
-------
Use base.user_admin for demo_invoice_deferred (never archived, stays
readable from any company), and False for demo_bill_deferred (a bill has
no salesperson).

opw-6106870

Forward-Port-Of: odoo/enterprise#113946

Steps to produce:
---
- Install the `Sales` module.
- Go to `Invoicing > Configuration > Payment Terms`.
- Open `Immediate Payment` and enable Early Discount.
- Set `Reduced Tax` to `Always (upon invoice)`.
- Go to Invoicing > Configuration > Taxes.
- Create a 21% tax with `Tax included`.
- Create a product with a sale price of 7.50 and assign the tax.
- Create a Sale Order with this product > Set Immediate Payment as payment term.

Issue:
---
- The untaxed amount is computed as 6.22 instead of 6.20.

Root cause:
---
- At [1], in `_add_base_lines_for_early_payment_discount`, the base lines generated for early payment discount were missing the `special_mode='total_excluded'`.
- Consequently, the tax engine interpreted these amounts as tax-included and attempted to recompute the untaxed base, resulting in an incorrect untaxed amount.

Solution:
---
- Add `special_mode='total_excluded'` to the base lines created for early payment discount computation.
- This ensures the discount amounts are treated as already tax-excluded.

[1]https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/addons/sale/models/sale_order.py#L515-L550

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

Forward-Port-Of: odoo/odoo#260480
Forward-Port-Of: odoo/odoo#255724

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114990
Forward-Port-Of: odoo/enterprise#113083

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

IM status on avatars in Discuss have been improved to properly mask the image [1]. To do so, this uses SVG and ForeignObject on top of mask, so that it can uses font-awesome icons such as `fa fa-circle` for online status.

This change introduced an accidental regression in Safari, where position of the offline status is wrong. This comes from a bug in Safari where some CSS inside foreignObject resets the position of the element to position 0, 0 on the global SVG [2] [3].

This affects offline status because this IM status has an `opacity-75`, intended to reduce distraction from the offline, but since this changes opacity this introduce the bug in Safari of mis-position.

This commit fixes the issue by moving the applied CSS to change opacity from `opacity-X` rules inside foreignObject to the parent `g` tag above `foreignObject`. That way, the element inside `foreignObject` has no change of opacity but instead the `g` has it, which is ok for Safari.

Note that this implementation assumes that change of opacity inside `foreignObject` is made only once and with `opacity-X` classnames.

[1]: https://github.com/odoo/odoo/pull/246182
[2]: https://github.com/bkrem/react-d3-tree/issues/284
[3]: https://bugs.webkit.org/show_bug.cgi?id=23113

Task-6143646

Before / After

<img width="308" height="579" alt="Screenshot 2026-04-21 at 12 51 52" src="https://github.com/user-attachments/assets/41596916-f371-407e-acb1-eb097c497360" /> <img width="310" height="584" alt="Screenshot 2026-04-21 at 12 51 20" src="https://github.com/user-attachments/assets/513df1f5-4cde-4cb7-8769-d6264dfb36a0" />

Forward-Port-Of: odoo/odoo#260341

**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  `stock` module.
* Go to  Settings and enable: 
     * Storage Locations (Warehouse).
     * Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
     * Set Type of Operation to Internal Transfer.
     * In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
     * Select the newly created Operation Type.
     * Add the created Product with quantity 4.4.
     * Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
     * Select the same Operation Type.
     * Add the same Product with quantity 48.8.
     * Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
     * Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.

**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).

**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:

https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205

- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.

**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats

- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.

---
opw-5932329

Forward-Port-Of: odoo/enterprise#114998
Forward-Port-Of: odoo/enterprise#110241

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