### Issue:

The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature.

### Steps to reproduce:

- Have 2 companies: company 1 and company 2
- Set the barcode nomenclature of company 1: default, company 2: GS1
- Incarnate a user allowed in both companies but with default company 1
- With company 2, create a product and set its barcode to 36939282410106
- From the main menu open the barcode app and scan 0136939282410106
#### > No product was found (even thought it is correct in GS1)

### Cause of the issue:

Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 
However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11
As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083
based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722

### Fix:

Setting the company slices the `current_company` in first position of the `allowed_company_ids`:
https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81
which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491
Note that passing the context in the arguments of the `main_menu` JSON  route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f

### Additional Issue:

The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Set the barcode nomenclature to GS1
- Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365
- From the main menu open the barcode app and scan 4133033710074365
#### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination)

opw-5847529

Forward-Port-Of: odoo/enterprise#112783
Forward-Port-Of: odoo/enterprise#111662

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112811
Forward-Port-Of: odoo/enterprise#107671

In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.

Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
    -  Never variant with at least two values
    -  MTO and manufacture
* Create a bom,
    - Company : company B
    - Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant

Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.

opw-5438723

Forward-Port-Of: odoo/enterprise#107122

### Steps to reproduce:
- Download Payroll app
- From the top bar 'Employees' > 'Employees', create a new employee
- From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB)
- Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated

> If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError**

### Cause of issue:
https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. 
https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17

### Fix:
Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`.

opw-5953671

Forward-Port-Of: odoo/enterprise#109986
Forward-Port-Of: odoo/enterprise#109823

`has_published_products` was previously computed recursively. For recursive fields, the ORM disables prefetch optimizations.

In 3ffca1961cb1671e7028dd4dceca82d2e74a2e21, the computation switched to `_read_group` to avoid loading all published products into cache and prevent memory issues. However, this introduced an N+1 pattern when evaluating:
```python
categories.filtered(lambda categ: categ.has_published_products)
```

As a result, query count became dependent on the number of active categories, which broke SQL performance tests when demo data were installed.

This commit updates the computation again to avoid recursion and restore ORM prefetch optimizations, making the number of queries independent of the number of active categories.

This commit also removes redundant checks already enforced by ORM `ir.rule`. For example, the following pattern evaluates `has_published_products` three times: once in the user domain, once in the access rule domain added by `search`, and once in the filter.
    
```python
domain = [("has_published_products", "=", True)]
categs = self.env["product.public.category"].search(domain)
categs.filtered("has_published_products")
```

runbot-234948

Forward-Port-Of: odoo/odoo#257071
Forward-Port-Of: odoo/odoo#256415

Steps to reproduce:
1- Install Inventory, Purchase and Manufacturing
2- Enable 'multi-step routes' in the settings
3- Create Product A and create a Bill of Materials (BoM type: subcontracting,  Component A)
4- Repeat the same for Products [B,C] with components [B,C] correspondingly.
5- Assign the same subcontractor to all of them
6- Create a Purchase Order for both Product A and Product B with vendor as the subcontractor and confirm it
7- Add a new order line with Product C and save

Description of issue:
A second resupply picking is created

Expected behavior:
Should group the new product's component with the existing picking

Why this happens:
When assigning the resupply picking for the new product's component, the search domain for the existing picking includes production_group_id, which is different for the added product.
This prevents merging of components into a single resupply picking despite sharing the same destination and purchase order

Fix:
We ignore production_group_id since it is not necessary in the resupply stock moves domain.

opw-5906451

Forward-Port-Of: odoo/odoo#251713

**Problem:**
The cost is not correctly computed on sale order 
line when the product is dropshipped.

**Steps to reproduce:**
- enable "margins" and "dropshipping" settings
- create a tracked, fifo product with dropship route
- add a vendor in the purchase tab
- confirm a sale order for 1 unit
- set a unit price of 10 in the PO and confirm it
- validate the dropship picking
- come back to the sale order and unhide de cost column

**Current behavior:**
the cost is 0

**Expected behavior:**
the cost should be 10 based on the unit price of the PO

**Cause of the issue:**
To compute the purchase price, when there is valued moves 
linked to the sale order line and the product is fifo/avco, 
we call _get_price_unit() on the moves.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/sale_stock_margin/models/sale_order_line.py#L21
Which uses the value of the moves
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/stock_move.py#L237-L243
But for dropshipped move the value on the moves is always 0.
So the return value will be 0 and purchase price will be 0.

**fix:**
- The idea of the fix is to use _get_value() instead of the move 
value for dropship moves. 
This approach is already used in the code inside 
_run_average_batch()
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/product.py#L474-L475

- In case there is not only dropship moves we need to do 
a weighted average


opw-6051004

Forward-Port-Of: odoo/odoo#256089

Steps to reproduce:
- Go to To-do
- Open a demo record (e.g., "Welcome Mitchell Admin")
- Click on an image
- Click on "Caption" from the toolbar
- Click on the image again

Description of the issue:
- When adding a caption, the parent paragraph block of sibling nodes is removed, making them direct children of the editable area.
- After adding a caption, reopening the powerbox does not show the caption button as active, allowing multiple captions to be added on the same image.

Cause:
- When the image has `display:block`, `closestBlock` returns the image itself as its closest block.
- As a result, when a caption is added to an image, its parent paragraph block is not split around the image even if the image has sibling nodes, and when `unwrapContents` is called, both the image and its siblings get unwrapped, making them direct children of the editable area.
- Since `closestBlock` is the image (and not a `<figure>`), the caption button in the toolbar is not marked as active even when a caption already exists, so clicking it again adds another caption instead of removing the existing one.

Solution:
- Instead of using the image's `closestBlock` directly, find the `closestBlock` of its parent element.
- This ensures the correct block is found even when the image has `display:block`.

task-6051549

Forward-Port-Of: odoo/odoo#256436
Forward-Port-Of: odoo/odoo#255064

There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in account_tax.py.

After 18.0, the tax-included behavior is controlled through the `price_include_override` field instead of `price_include`. However, this field was not added in the forbidden fields, allowing users to modify tax inclusion while a POS session is open.

This bypasses the safeguard and can lead to inconsistencies, as the POS caches tax configuration at session start.

For example, changing this setting mid-session may differences between POS receipts and backend invoices.

By adding `price_include_override` to the forbidden fields,
the UserError can properly be raised.

Additional note: test_fiscal_position_between_frontend_and_backend was updated to close the POS session before changing taxes since the safeguard now correctly blocks this.

Related ticket: opw-6042367

Forward-Port-Of: odoo/odoo#257035
Forward-Port-Of: odoo/odoo#254487

## Versions
18.0+

## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.

## Steps to reproduce
- Create a new SO for any customer:
  - Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
  - Save manually;
  - Change the product for a combo or variant one (e.g. "Customizable Desk");
  - With the opened dialog, change from browser tab then come back;
  - The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).

## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.

## Test
No test as we cannot simulate a browser tab change then come back to the first tab.


opw-5494089

Forward-Port-Of: odoo/odoo#257846
Forward-Port-Of: odoo/odoo#247797

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112811
Forward-Port-Of: odoo/enterprise#107671

**Steps to reproduce:**
- Create 2 products, set their price to 0
- Create a combo product, set it's price to 10
- The combo choices should be the 2 products created before
- Go to the self order, order the combo and change the qty to 3
- The price is 30, correct in the frontend
- Go to the order in the backend, the price is 0

**Why the fix:**

In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines.
This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code
https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 
But the total price has been computed to zero, so the previously computed price_unit is overriden and set to zero.

We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line.

The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation.

opw-6032408

**Problem:**
The cost is not correctly computed on sale order 
line when the product is dropshipped.

**Steps to reproduce:**
- enable "margins" and "dropshipping" settings
- create a tracked, fifo product with dropship route
- add a vendor in the purchase tab
- confirm a sale order for 1 unit
- set a unit price of 10 in the PO and confirm it
- validate the dropship picking
- come back to the sale order and unhide de cost column

**Current behavior:**
the cost is 0

**Expected behavior:**
the cost should be 10 based on the unit price of the PO

**Cause of the issue:**
To compute the purchase price, when there is valued moves 
linked to the sale order line and the product is fifo/avco, 
we call _get_price_unit() on the moves.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/sale_stock_margin/models/sale_order_line.py#L21
Which uses the value of the moves
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/stock_move.py#L237-L243
But for dropshipped move the value on the moves is always 0.
So the return value will be 0 and purchase price will be 0.

**fix:**
- The idea of the fix is to use _get_value() instead of the move 
value for dropship moves. 
This approach is already used in the code inside 
_run_average_batch()
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/product.py#L474-L475

- In case there is not only dropship moves we need to do 
a weighted average


opw-6051004

Forward-Port-Of: odoo/odoo#256089

Steps to reproduce:
1- Install Inventory, Purchase and Manufacturing
2- Enable 'multi-step routes' in the settings
3- Create Product A and create a Bill of Materials (BoM type: subcontracting,  Component A)
4- Repeat the same for Products [B,C] with components [B,C] correspondingly.
5- Assign the same subcontractor to all of them
6- Create a Purchase Order for both Product A and Product B with vendor as the subcontractor and confirm it
7- Add a new order line with Product C and save

Description of issue:
A second resupply picking is created

Expected behavior:
Should group the new product's component with the existing picking

Why this happens:
When assigning the resupply picking for the new product's component, the search domain for the existing picking includes production_group_id, which is different for the added product.
This prevents merging of components into a single resupply picking despite sharing the same destination and purchase order

Fix:
We ignore production_group_id since it is not necessary in the resupply stock moves domain.

opw-5906451

Forward-Port-Of: odoo/odoo#251713

## Versions
18.0+

## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.

## Steps to reproduce
- Create a new SO for any customer:
  - Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
  - Save manually;
  - Change the product for a combo or variant one (e.g. "Customizable Desk");
  - With the opened dialog, change from browser tab then come back;
  - The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).

## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.

## Test
No test as we cannot simulate a browser tab change then come back to the first tab.


opw-5494089

Forward-Port-Of: odoo/odoo#257846
Forward-Port-Of: odoo/odoo#247797

## Versions
18.0+

## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.

## Steps to reproduce
- Create a new SO for any customer:
  - Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
  - Save manually;
  - Change the product for a combo or variant one (e.g. "Customizable Desk");
  - With the opened dialog, change from browser tab then come back;
  - The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).

## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.

## Test
No test as we cannot simulate a browser tab change then come back to the first tab.


opw-5494089

Forward-Port-Of: odoo/odoo#257482
Forward-Port-Of: odoo/odoo#247797

Issue:
Export XML button doesn't produce the same file as the send button.

Steps to reproduce:
- Company in Spain with Peppol (work with any Peppol country)
- Partner in Croatia
- Select eInvoice Type as "EU Standard (Peppol Bis 3.0)"
- Create an invoice
- Confirm it
- Click on the Wheel -> Download

Current behavior:
- without l10n_hr_edi: only "PDF" and "PDF without Payment"
- with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file

Cause:
"Export XML" button appear only if:
- there is a default ubl option for the partner country
- there is an XML attached to the invoice when clicked it exports the corresponding one.

Whereas, the 'send' button rely on:
1) the partner defined edi format,
2) the default ubl option for the partner country
3) "ubl_bis3"

To be noted:
The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice.

opw-5943500

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

### Issue before this commit:
When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'.

### Steps to reproduce the issue:
1. Select two or more companies from multi company menu
2. Accounting / Reporting / Ledgers / General Ledger
3. Posted Entries, Accrual Basis button
4. Pick Consolidation
5. Error

### Cause of the issue:
When more than one company is selected, the General Ledger consolidation groups journal entries by multiple parameters in an increasingly strict hierarchy. One of these parameters is account_code, which is required only in a multi-company context (as account_id alone is sufficient when a single company is selected).
However, the SQL query was not properly adapted to handle this case. The account_code field was used as a grouping key but was not retrieved from the database, resulting in a KeyError.

### Reason to introduce the fix:
To ensure that the General Ledger consolidation can be correctly displayed in a multi-company context and to prevent runtime errors.

opw-5933074

Forward-Port-Of: odoo/enterprise#112738
Forward-Port-Of: odoo/enterprise#109036

__

## Short functional explanation of the error
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48.

## Reproduction Steps
1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang.
2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time.
3. Open Attendances.

### Expected behavior
When we hover the name of our employee, we can see in white on green background 0/40h.

### Unexpected behavior
Instead, we see 0/48h.

## Origin of the issue
This line:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419
is used to retrieve the correct date. We assume that `end_datetime`
will be set at midnight, so subtracting one second gives us the day
before, allowing us to ignore the date of `end_dt`, for which we don't
need to compute the intervals.
However, this doesn't take into account different time zones. Indeed,
we compute `end_datetime_adjusted` from `end_datetime`, which has
the user timezone, and not UTC, as defined here:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402
As a result, if we set the user timezone to Pyongyang, `end_datetime`
will be set at 8am, and `end_datetime_adjusted` will lead to the same
date, instead of a day before. Hence, we would compute an additional
interval for an additional day, which would in the end give us 48
hours expected instead of the 40 hours indicated in the contract.
Therefore, we have to take into account the time zones, hours, minutes
and seconds when checking the start and end dates.

__
opw-5937298

Forward-Port-Of: odoo/enterprise#111332
Forward-Port-Of: odoo/enterprise#110011

### Issue:

The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature.

### Steps to reproduce:

- Have 2 companies: company 1 and company 2
- Set the barcode nomenclature of company 1: default, company 2: GS1
- Incarnate a user allowed in both companies but with default company 1
- With company 2, create a product and set its barcode to 36939282410106
- From the main menu open the barcode app and scan 0136939282410106
#### > No product was found (even thought it is correct in GS1)

### Cause of the issue:

Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 
However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11
As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083
based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722

### Fix:

Setting the company slices the `current_company` in first position of the `allowed_company_ids`:
https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81
which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491
Note that passing the context in the arguments of the `main_menu` JSON  route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f

### Additional Issue:

The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Set the barcode nomenclature to GS1
- Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365
- From the main menu open the barcode app and scan 4133033710074365
#### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination)

opw-5847529

Forward-Port-Of: odoo/enterprise#112783
Forward-Port-Of: odoo/enterprise#111662

Add two new configurable options to the FedEx shipping integration:

1. ETD with Odoo Invoice (new documentation_type option): New 'ETD with Odoo Invoice' option in the Generate Invoice setting. When selected, the module uploads the Odoo-generated invoice PDF to FedEx Documents API (encodedmultiupload endpoint) and references it in the shipment request as an ETD attached document. This replaces the FedEx-generated commercial invoice with the actual Odoo invoice, ensuring export documents match accounting records. Requires a posted invoice on the SO before shipping. Note: FedEx Documents API uses a different base URL (documentapi.prod.fedex.com) than the Ship API.

2. Enhanced References (new Boolean field): When enabled, shipment package references include up to 3 fields:
   - PO Number: Customer Reference from SO (client_order_ref), or SO number if not set
   - Customer Reference: SO number
   - Invoice Number: Odoo posted invoice number When disabled, existing behavior is preserved (PO Number = SO number).

Both features are opt-in via carrier configuration fields, preserving full backward compatibility with existing setups.

Click and collect widget is not supported for rental products

Steps to reproduce:
-------------------
* Enable "Click and collect" in setting and set up warehouses
* Create a rental product
* Add a unit of the product in one of the warehouses
* Rent that product for a period
* Go on the website>shop>the product
* The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page

Observation:
-------------
The implementation of click and collect does not include a sale_renting module, this entails that [click and collect](https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36) and [openLocationSelector](https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54) don't have any information about the rental periode

The rental date range is shown when the product is possible to rent and the rental period is only set in the  xml file:
https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90

Since openLocationSelector don't have access to the rental period, it can't update the necessary information to work with rental products.
For example, the free_qty should change depending on the rental period.

opw-5365564

**Steps to reproduce:**
* install `account_iso20022` and `l10n_ch`.
* Set Swiss ISO20022 in outbound payments in the Bank journal.
* Create two vendor payments: one with a Swiss QR_iban bank account (CH...) and one with a foreign bank account (DE...).
* Group them into a batch payment and download the XML.

**Observed behavior:**
* Swiss IBAN creditor accounts are rendered as `<CdtrAcct><Id><Othr><Id>` instead of `<CdtrAcct><Id><IBAN>`.
* Foreign IBAN creditor accounts (e.g. DE) correctly use `<IBAN>`.
* UBS and other Swiss banks reject the XML file due to the inconsistency.

**Cause:**
* `_get_CdtrAcct()` delegates to `_is_bank_account_qr_iban()` to decide between `<IBAN>` and `<Othr><Id>`.
* Swiss IBANs with an IID in the range 30000–31999 are classified as QR-IBANs, causing them to fall into the `<Othr><Id>` path even when they are standard IBAN accounts eligible for the `<IBAN>` tag.

**Fix:**
* Override `_get_CdtrAcct()` in the Swiss ISO20022 journal model to always emit `<CdtrAcct><Id><IBAN>` for any IBAN-type account when `payment_method_code == 'iso20022_ch'`, regardless of QR-IBAN classification.
* Non-IBAN accounts (e.g. postal accounts) still fall through to the base implementation using `<Othr><Id>`.

Ref: https://www.bib.eu/uploads/2020/04/Payment_import.pdf

opw-6061266

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#255478

__Problem__
Employees could not see their remaining leave days and the view always showed 0 left days. This happened when multiple allocations existed across different years.

The view relied on `min(id)`/earliest allocation logic and a default current-year domain. When the earliest allocation belonged to a previous year:

* The record holding the remaining balance was filtered out by the year domain.
* Expired allocations were still included in totals.

As a result, remaining days were either incorrect or always displayed as zero.

__Fix__
* compute remaining balance on the latest non-expired allocation `max(id)`
* Only sum non-expired allocations when computing the available balance.
* changes in leave subtraction logic:
  * If a leave falls entirely in a non-expired allocation → subtract fully.
  * If it falls entirely in expired allocations → do not subtract.
  * If it spans expired and non-expired allocations → subtract only the portion after the last expiry date.

* When subtracting partial leaves, count only actual working days:
  * Use the employee’s resource calendar (`resource_calendar_attendance`) to get the weekend days
  * Exclude public holidays
* Apply the same proportional logic to hours.

__Result__
* Remaining leave days are now always visible.
* Expired allocations no longer affect current availability.

_Backwards compatibility note:_
* Splitting leaves across expired and non-expired allocations happens on sum(allocations) level, not on the actual leave lines level.

so leaves are not split into two records when they span expired and non-expired allocations. The leave record remains whole, but only the portion that falls into non-expired allocations is counted against the available balance.

__Example__
allocation 2025: 20 days (expires 31 Dec 2025)
allocation 2026: 20 days (expires 31 Dec 2026)
Public holidays: 2 Jan, 31 Dec
weekends: Saturdays and Sundays

Leave: 15 Dec 2025 to 6 Jan 2026 (15 days total)
* 2025 is expired so counting starts from 1 Jan 2026
* Interval days: 1 Jan to 6 Jan = 6 days
* Public holiday on 2 Jan → exclude
* Weekend on 4 Jan and 5 Jan → exclude
* Working days counted: 6 - 3 = 3 days subtracted from 2026 allocation.

report will show:
2025: 20 days allocated, 15 days taken, 0 days left (all expired) 2026: 20 days allocated, 0 days taken (leave not split), 17 days left

-opw-5169606

Click and collect widget is not supported for rental products

Steps to reproduce:
-------------------
* Enable "Click and collect" in setting and set up warehouses
* Create a rental product
* Add a unit of the product in one of the warehouses
* Rent that product for a period
* Go on the website>shop>the product
-> The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page

Observation:
---------------
The implementation of click and collect does not include a sale_renting module, this entails that click and collect and openLocationSelector has no information about the rental period.
https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36 

https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54-L61
The rental date range is shown when the product is possible to rent and the rental period is only set in the [xml](https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90) 

Since openLocationSelector don't have access to the rental period, it can't update the necessary information to work with rental products.
For example, the free_qty should change depending on the rental period.


opw-5365564

When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked.

### Steps to reproduce:
* Create a product tracked by lot and lot_valuated
* Create a BoM for this product
* Create a MO for this product
* Confirm and Produce all
* erase the lot and save -> the MO is deadlock, it's not possible to modify the lot number, nor it's possible to unbuild.

### Current behavior:
A user is able to erase a lot/SN from a MO of a lot_valuated product.

### Expected behavior:
It should not be possible to erase a lot/SN form a MO of a lot_valuated product.

### Observation:
When the MO is done, its valuation will be calculated which in our case, it means, we have to have a lot number. When trying to add a lot/SN of a MO where it has been erased, we will remove the quantities from the previous lot, but in our case, since we don't have one, it will trigger the user error. https://github.com/odoo/odoo/commit/33e192de30526ea7fe320bcaa7a16dac8108feff
This error is not triggered when removing the SN/lot because when we remove the value, it will be update to False which means it will skip _update_svl_quantity():
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L35-L36
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L62-L65
This use case is also protected when creating a product tracked by lot but not lot_valuated: https://github.com/odoo/odoo/commit/4963103e5587d36364b8df84d0b3407a1977efdf

opw-6039885

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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

Forward-Port-Of: odoo/odoo#254871

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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