Before this commit:

- Product retrieval during import relied on exact name match and substring (ilike) search.
- Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`.
- Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with
  `Wireless bluetooth speaker battery`), leading to unrelated matches.

After this commit:

- Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`.
- Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names.

Technical:

- Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive.
- Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match.
- Added system parameter for configurable product name similarity threshold.

task-5951469

Forward-Port-Of: odoo/odoo#258709
Forward-Port-Of: odoo/odoo#252147

**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`.
* Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.


task: 5408192

Forward-Port-Of: odoo/enterprise#103846

## Context
On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it.

## Issue
When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size.

## Steps to reproduce
1. Install the *eCommerce* (`website_sale`) app.
2. Create a product and set a picture for it.
3. Go to that product's page in the Website app and open the website editor.
4. Click on the picture and replace it.
5. **The options to transform the picture are not displayed.**

## Cause
The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16

## Solution
We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173

We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo.

On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are:
- Description
- Tooltip
- Transform (*"Transform the picture"*)
- Size

## Tests
The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it.

https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16

## Options displayed
|   | Before this commit  | After this commit  | Previous versions |
|---|---|---|---|
|  **Before replacing the image**  | Media, Re-order | Media, Re-order  | Media, Re-order
|  **After replacing the image**  | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality


opw-5251864

Forward-Port-Of: odoo/odoo#247706
Forward-Port-Of: odoo/odoo#241071

[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs
Refund orders paid through eWallet top-up can have a net total of 0, which
made refund detection based only on negative totals inconsistent. As a result,
some refund flows were treated as normal invoices and refund tax/invoice signs
were incorrect.

Steps to reproduce:
-------------------
* Configure an eWallet program in POS.
* Create and pay a POS order for one product, then invoice it.
* Refund that order and choose eWallet as refund payment method (refund + top-up).
* Validate and inspect the generated accounting document.

> Observation:
The refund flow may not be consistently treated as a refund when the order’s
net amount is 0, causing incorrect invoice move type/sign handling and wrong
tax booking behavior.

Why the fix:
------------
Refund detection now also relies on `refunded_order_id` in key paths:
* `_compute_prices`: apply refund factor when order is linked to a refunded order
  (or already negative), so totals/taxes keep refund semantics.
* `_prepare_invoice_vals`: create `out_refund` when the order is linked to a
  refunded order (or has negative total), ensuring a credit note is produced.
* `_prepare_base_line_for_taxes_computation`: consider refund context with
  `is_refund` or negative total for tax base sign consistency.

This keeps existing negative-total refund behavior while correctly handling
refund+eWallet cases where the arithmetic total can be 0.

opw-5426818

Forward-Port-Of: odoo/odoo#259217
Forward-Port-Of: odoo/odoo#247948

This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location):
1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273
2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Create a storable with an avco perpetual valuation with a cost of 5$
- Click the `On hand` smart button > Update Quantity
- Put 1 unit in WH/Stock and 2 units in Subcontracting
- Go to Inventory > Reporting > Stock
#### > The unit cost of your product is 15$ instead of 5$
- Click on locations on the line and remove the `internal` filter
#### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$

### Cause of the issue:

The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines:
https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363

### Additional issue:

The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it.

opw-5959720
opw-5883980

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

Forward-Port-Of: odoo/odoo#257103

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus.

Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657)

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

Forward-Port-Of: odoo/odoo#259486
Forward-Port-Of: odoo/odoo#250294

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

Steps to reproduce
------------------
1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant)
2. Open Bar, go to its self-order mobile menu, place an order
3. Go back, open Restaurant, click on Orders tab

-> The Bar's self-order shows up in the Restaurant's order list.

What's happening
----------------
In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company.

But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config).

The fix
-------
We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method.

opw-6068187

Forward-Port-Of: odoo/odoo#258712

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

Forward-Port-Of: odoo/enterprise#111833

This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location):
1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273
2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Create a storable with an avco perpetual valuation with a cost of 5$
- Click the `On hand` smart button > Update Quantity
- Put 1 unit in WH/Stock and 2 units in Subcontracting
- Go to Inventory > Reporting > Stock
#### > The unit cost of your product is 15$ instead of 5$
- Click on locations on the line and remove the `internal` filter
#### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$

### Cause of the issue:

The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines:
https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363

### Additional issue:

The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it.

opw-5959720
opw-5883980

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

Forward-Port-Of: odoo/odoo#257103

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

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

Forward-Port-Of: odoo/odoo#259076
Forward-Port-Of: odoo/odoo#257012

Steps to reproduce
------------------
1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant)
2. Open Bar, go to its self-order mobile menu, place an order
3. Go back, open Restaurant, click on Orders tab

-> The Bar's self-order shows up in the Restaurant's order list.

What's happening
----------------
In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company.

But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config).

The fix
-------
We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method.

opw-6068187

Forward-Port-Of: odoo/odoo#258712

…e_journal_ids and it differs from the current journal_id

This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company."

Description of the issue/feature this PR addresses:

The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company."

Current behavior before PR:

When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal.

Desired behavior after PR is merged:

When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it.


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

Forward-Port-Of: odoo/odoo#259573

**Purpose:**
Since a stock.quant is a combination of the stock move lines of a product
and a location, it should be restricted by the product's company.

**Before this commit:**
In a multi-company environment. If a purchase order with product from
company 1 is being confirmed, received, and validated when company 2 is
being selected as the primary active company while company 1 is also
checked. It will create a stock.quant that is searchable for company 2.
However, it will raise an error when company 2 is trying to access it.

**After this commit:**
Even if the stock.quant is created when company 2 is the primary active
company, it will not be searchable for company 2 since the product's
company is company 1.

**Steps to Reproduce on Runbot:**

- Create a storable product exclusive to Company A
- Create & validate a receipt for that product in Company A.
- Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible.

opw-6082330

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

Forward-Port-Of: odoo/odoo#259733
Forward-Port-Of: odoo/odoo#257211

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.

**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.

- This leads to runtime issues such as:
    - Cannot convert field to SQL because it is not stored
    - Failures in search, domains, and reporting
    - Inconsistent behavior depending on usage context

- Currently, no validation prevents users from configuring such invalid related fields.

**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.

- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.

This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.

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

Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404

Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.

Steps to Reproduce on Runbot:

1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location. 
5. Create a new route.
6. Create new rules on this new route with the following configurations:
   1. Rule 1
      1. Action: Pull
      2. Source location: WH/Stock
      3. Destination location: Partners/Customers
      4. Operation type: The new pick operation type
   2. Rule 2
      1. Action: Push
      2. Source location: New pack location
      3. Destination location: WH/Output
      4. Operation type: Pack
   3. Rule 3
      1. Action: Push
      2. Source location: WH/Output
      3. Destination location: Partners/Customers
      4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it. 


opw-6026918

Forward-Port-Of: odoo/enterprise#113879
Forward-Port-Of: odoo/enterprise#112543

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

Forward-Port-Of: odoo/enterprise#111833

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#102109
Forward-Port-Of: odoo/enterprise#98571

Currently, when a subscription payment is processed through a provider
configured to use as outstanding account the bank default account,
the resulting invoice may remain in an 'open' state even though
the payment transaction is 'done'.
This type of configuration is usually done when users want to skip
the bank reconciliation process, and just create payments without
the need to reconcile the payments with transactions.

Steps to reproduce:
- In Settings, under Sales > Invoicing, disable Automatic Invoice
- Activate demo payment method
- In the main Bank account add the default account as outstanding
  account for demo payment method.
- Create a sales order with a subscription product
- Open Preview
- Pay
- Go back to the sales order and open the created invoice

Issue:
The invoice is created and the payment is registered, but
the invoice remains 'Not Paid'.

Analysis:
The invoice and the payment move lines are not automatically reconciled
during the post-processing of the transaction, leaving the invoice
unbalanced.

opw-5869303

### **Description of the issue/feature this PR addresses:**

**Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However, when a user configures a sub-location on the Receipt Operation Type, the picking destination is correct, but the move lines are defaulted to the main warehouse. This mismatch causes the Forecasted Quantity to not increment for the intended sub-location

**Solution:** Prioritize the `default_location_dest_id` before falling back to the default stock location

opw-6032018

### **Current behavior before PR:** 
When confirming a PO, the `location_final_id` on stock moves defaults to the `lot_stock_id`, regardless of the specific destination set on the Operation Type. This causes a mismatch in 1-step receiving flows where a sub-location (e.g., WH/Stock/Test) is intended, since the move lines revert to the root warehouse location (WH/Stock). Thus, the forecasted quantity for the specific sub-location doesn't increment as expected.

### **Desired behavior after PR is merged:** 
The `_get_final_location_record` method will now evaluate if the Operation Type's `default_location_dest_id` is a child of the warehouse's main stock. If it is, the sub-location is used as the `location_final_id` for the moves and move lines. This ensures that the forecasted quantity reflects the intended destination upon PO confirmation while still maintaining the fallback to the warehouse root for standard multi-step routes.




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

Forward-Port-Of: odoo/odoo#256725
Forward-Port-Of: odoo/odoo#254527

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Steps to reproduce:
-------------------
1. Activate JPY and create a JPY bank journal with ISO20022 as an
   outgoing payment method
2. Create a vendor (with a country) and add a trusted bank account
3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it
   using the ISO20022 method on the JPY journal
4. Create a batch payment containing that payment, with Batch Type
   Outbound, on the JPY journal, with ISO20022 as payment method
5. Validate the batch — the XML file is generated and attached
6. Download it

-> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has
no decimals. The file is rejected by banks.

The fix:
--------

Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d:

> Generating the xml file for iso20022 always generates the amount with
two decimals which is hard coded and can cause error for currencies without decimals for example JPY.
> The fix is to have the currency decimal number dynamically set through
the currency decimal places field.

opw-6103849

Forward-Port-Of: odoo/enterprise#113296

This pull request introduces key usability improvements for the rental app in One-App Free environments and refreshes the associated demo data across all related modules. 

Previously, essential rental options were hidden from standard menus, requiring technical workarounds to enable basic capabilities. To resolve this, rental menus and settings have been reorganized to expose these core features directly in the base app. Additionally, the pickup and return time fields have been migrated from `website_sale_renting` to the core `sale_renting` module, and the default rental date computation logic has been unified so both backend and frontend flows share the exact same logic.

Furthermore, following recent architectural changes in the rental app (#104380), the existing demo data had become outdated and lacked diversity, as most products were limited strictly to daily rentals. This PR comprehensively updates the demo data to align with the new system logic, providing a much wider range of configuration scenarios to ensure robust and accurate testing going forward.

task-5865007

This PR also includes https://github.com/odoo/enterprise/pull/109498 (task-6003684) to resolve conflicts and speedup the merge 🚀

See also:
- https://github.com/odoo/upgrade/pull/9897

Adds support for generating SAT (Mexican tax authority) trial balance reports in supplementary (complementary) format, as required by SAT specifications.

Changes:
- Add default value for submit_type in SAT XML generation to fix tests that call the method directly without going through the wizard
- Add new tests for normal (TipoEnvio=N) and supplementary (TipoEnvio=C) formats
- Verify that FechaModBal attribute is correctly included only for supplementary reports
- Verify that filenames correctly use BN (normal) or BC (complementary) suffixes

The SAT technical specification requires:
- TipoEnvio="C" (complementary) for supplementary balance sheets
- FechaModBal attribute (date of last accounting modification) when tipo is C
- File naming convention: RFC+Year+Month+BN (normal) or BC (complementary)

SAT technical specification:
https://wwwmat.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461173762094&ssbinary=true

Ticket: https://www.odoo.com/es_ES/my/tasks/6025590

@moduon MT-14181

### Description of the issue/feature this PR addresses:

The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot.

This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small.

### Current behavior before PR:

The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found.

This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times.

### Desired behavior after PR is merged:

The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval.

This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios.

### Benchmarks

Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board.

| Work Order Duration | Before | After |
| --- |---|---|
| 1sec | ~2.5min | <1sec |  
| 1min | ~2sec | <1sec |

### References

opw-5437256


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

When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed.

### **Steps to reproduce:**
1) Install Timesheet Grid.
2) Assign a flexible working schedule (40 hrs/week, 8 hrs/day) to an admin.
3) Enter timesheets with 8 hours per weekday for a full month (except Feb).
4) Open the timesheets grid month view.

Note: current formula correctly calculates for feb month **((40/7)** * **28) = 160**

### **Observed behavior:**
The weekly view shows correct totals, but the monthly view displays a deficit (176 h with -1:08 h), despite all working days being fully completed.

<img width="1920" height="366" alt="image" src="https://github.com/user-attachments/assets/df98c3e0-ee89-455d-86c6-7941ba0cb7a8" />


### **Expected behavior:**
The monthly view should correctly calculate the required hours i.e 176 h

<img width="1909" height="357" alt="image" src="https://github.com/user-attachments/assets/c082953a-62ad-4096-8774-76d9ff7b3b25" />


### **Root Cause:**
The method [_count_daily_working_hours](https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L82) calculated `full_time_required_hours` for a period by dividing the weekly required hours by 7 (including weekends) and multiplying by the total calendar days in the period at [1]. This gave incorrect required hours for months that have extra weekend days.

[1]- https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L115

### **Fix:**
Update the computation to divide the weekly `full_time_required_hours` by `5` (standard working days) and multiply by the actual number of weekdays in the requested period.

**Example calculation for the month March 2026:**

|  | Formula | Values | Calculation | Result |
|--------|--------|--------|--------|--------|
| Before Fix | round(full_time_required_hours / 7 * (delta.days + 1), 2) | full_time_required_hours = 40, delta.days + 1 = 31 | round(40 / 7 * 31, 2) | **177.14 h** |
| After Fix | round((full_time_required_hours / 5) * working_days_in_period, 2) | full_time_required_hours = 40, working_days_in_period = 22 | round((40 / 5) * 22, 2) | **176.00 h** | 

**opw-5966769**

1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)

To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
    result = func()
             ^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
    edi_users._peppol_get_message_status()
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
    processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
    peppol_response = uuid_to_record[uuid]
       ^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```

task-None

Description of the issue/feature this PR addresses:

When visualizing the structure of a BOM with subcontracted components, the subcontracting cost is omitted if no supplierinfo record exists with a `min_qty` less than or equal to the requested quantity.

This leads to an inconsistent experience compared to regular components, which still show a price by selecting the closest lower `min_qty`. For subcontracted components, if the requested quantity does not match any valid `supplierinfo`, the cost line silently disappears from the report.

Current behavior before PR:

The subcontracting cost is not shown in the BOM cost structure if no `supplierinfo` matches the requested quantity (i.e., `min_qty > quantity`).

Desired behavior after PR is merged:

If no matching supplier is found for the requested quantity, the fallback logic uses any available supplierinfo (as already done in `_format_route_info`), ensuring a price is shown for subcontracted lines. This guarantees the BOM cost structure always includes the subcontracting cost, making the report complete and coherent.

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

This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0

Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation

To reproduce the issue:
(Company in USD)
1. Enable EUR and define the rates as followed:
   - Yesterday: 2
   - Today: 2.5
2. Create a product category:
   - Method: Standard
   - Valuation: Automated
3. Create a product P in that category
   - Cost: 10 USD
4. [Yesterday] Confirm a PO in EUR with 1 x P
5. [Yesterday] Receive it
6. Bill

Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form.

Since https://github.com/odoo-dev/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7, in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict.

opw-5905197

Description of the issue/feature this PR addresses:

This is a follow-up to #250904.

The original 17.0 fix filtered inaccessible x2many records reused from cache during web_read. However, while forward-porting the fix to 18.0, additional issues were revealed.

The original issue is still cache pollution: web_read may reuse cached x2many ids that are not accessible anymore with the current record rules/context, and should neither expose them nor crash when formatting the result.

The 18.0 investigation showed that the first approach was not enough in all cases:

* using search([('id', 'in', ...)]) to filter x2many records is not always safe, as some models can override search() and raise errors
* using _filtered_access('read') unconditionally can also be too aggressive when the current user has no general read access on the comodel, as it may remove valid x2many values and break existing flows.

This PR backports the adjusted logic from the 18.0 forward-port to 17.0, so that 17.0 stays aligned with the later versions.

Current behavior before PR:
Even after the previous fix, web_read can still mishandle polluted cached x2many values in some cases, either by crashing while trying to filter/order the records, or by over-filtering them when the user has no general read access on the comodel.

Desired behavior after PR is merged:
web_read should keep filtering polluted x2many values when the user has read access on the comodel, while avoiding regressions for fields whose comodel is not generally readable by the current user.

The x2many values are therefore filtered in a safer way, aligned with the logic introduced in the 18.0 forward-port.

Backport-Of: #257517

X-original-commit: 05ded3eda89fb8ff9aafa62f314a9d5d4677d292 (cherry picked from commit 7eec72aadc294b1c2780e601e81636cffcc4965d)

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