Currently, an error occurs when reloading a chart template.

Steps to Reproduce:
 - Install the `Accounting` module with demo data.
 - Go to `Accounting` > `Configuration` > `Accounting` > `Chart of Accounts`.
 - Open the `Current Assets` account and remove its account code.
 - Go to `Settings` and click the `Reload` button under `Fiscal Localization`.

`TypeError: expected string or bytes-like object, got 'bool'`

After this [recent commit], account codes became optional and can be removed. As a result, 
when the code is removed from the Fixed Assets account and the chart template is reloaded, the 
reload process tries to match template accounts [1] with existing accounts [2]. It retrieves the 
existing account using its id [3] and correctly finds the account record, but its code field is False. 
Later, when the reload logic compares the existing account code with the template account code, 
it attempts to use account code in a regular expression, which raises error [4].

This commit ensures that accounts without a code are treated as having a non-matching code.

[recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277

[1]- https://github.com/odoo/odoo/blob/b04678b130438d5ee1605fadb9ca567930691fdf/addons/account/models/chart_template.py#L1153-L1155

[2]: https://github.com/odoo/odoo/blob/b04678b130438d5ee1605fadb9ca567930691fdf/addons/account/models/chart_template.py#L332

[3]: https://github.com/odoo/odoo/blob/b04678b130438d5ee1605fadb9ca567930691fdf/addons/account/models/chart_template.py#L435

[4]- https://github.com/odoo/odoo/blob/b04678b130438d5ee1605fadb9ca567930691fdf/addons/account/models/chart_template.py#L439

sentry-7556472625

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

When validating a POS order containing a product tracked by lots, an error about duplicate lot numbers is raised if the lot name can be read as a GS1 barcode (e.g. "10156": "10" is the GS1 Application Identifier for Batch/Lot) while the company uses a GS1 nomenclature and the Barcode app is installed.

Steps to reproduce:
-------------------
* Install Barcode, POS and Inventory, enable lots & serial numbers
* Set the barcode nomenclature to "Default GS1 Nomenclature"
* Create a product tracked by lots and a lot named "10156" (any name starting with "10"), set an on-hand quantity for it with this lot
* On the "PoS Orders" operation type, enable both "Create New" and "Use Existing ones" for lots/serial numbers
* In POS, sell the product with lot "10156" and validate the order

> Observation:
The order fails to validate with a duplicate lot number error: the search for existing lots does not find lot "10156", so the POS tries to create it again and hits the unique constraint on stock.lot.

Why the fix:
------------
With stock_barcode installed, `stock.lot._search` preprocesses any domain on `name` with `_preprocess_gs1_search_args` so that scanned GS1 barcodes can match lot records. The lot names sent at order validation by `_create_production_lots_for_pos_order` are real lot names coming from the order lines, not scanned barcodes, but "10156" is decomposable as a valid GS1 lot ("10" + "156"), so the search domain became `('name', '=', '156')` and missed the existing lot. Skip the GS1 preprocessing in that search with the existing `skip_preprocess_gs1` context key, as already done in `product` and `stock`.

opw-6274744

Forward-Port-Of: odoo/odoo#269787

Currently when the user receives a perishable product that expires in future, it is considered for reordering regardless if the user has maximum quantity or not.

## Steps to produce:
- Install Inventory
- Go to settings > Enable 'Lots and Serial Numbers' and 'Expiration Dates'
- Create a product 'Vegetable Oil' that is tracked by lots.
- Enable Expiration date in the 'Inventory' Section and set Removal date to 2.
- Create a receipt for 'Vegetable oil' with Demand 10 and mark it as todo
- Details > Set 'Expiration Date' into the future > Set a Lot Number and Save
- Validate the receipt
- Open Product Form for Vegetable oil > Reordering Rules.
- Create a new Reordering rule with Min 5 and Max 10 and save.

## Observed Behavior:
The forecasted quantity is calculated as zero, resulting in a quantity to order of 10, even though no replenishment is actually required. The product already satisfies the maximum quantity defined on the reordering rule, and there is no existing demand, as there are no delivery orders or sales order reservations for the product.

**Why this is an issue:**
When the user navigates from the product form to the On Hand Quantity view to verify the stock situation, the forecasted quantity is shown as 10. This is inconsistent with the value displayed on the reordering rule, creating confusion and making it difficult to understand the actual inventory status.

In addition, if the product is configured with a Buy route, running the `Procurement: Run Scheduler` action repeatedly generates new purchase orders for the perishable product. Even if the generated purchase orders are cancelled or completed, since newly purchased stock will also have an expiration date. As a result, the same incorrect forecast calculation occurs again, causing the scheduler to continuously create new purchase orders and leading to an endless replenishment cycle if they expire within horizon days.

## Root cause:
When an orderpoint is created or updated, `_compute_qty_to_order` [1] is triggered. This method calls `_compute_qty_to_order_computed` [2] which accesses the forecasted quantity, causing its compute method to called.

The forecast computation retrieves context from `_get_product_context` as seen in [3], where the lead horizon date
(route lead time + horizon days configured in settings) is passed as `to_date` at [4]. It then reads the product's `virtual_available` quantity using the orderpoint context at [5].

This ultimately invokes `_compute_quantities`, which delegates the calculation of `virtual_available` to `_compute_quantities_dict`, as shown in [6].

As a result, `max_date` is set to the lead horizon date at [7] (for example, one year in the future). Since the product expires before that date, it is included in `expired_unreserved_quant_res`, causing `virtual_available` to be reduced to zero at [8].

Consequently, the forecasted quantity also becomes zero at [9]. Because the forecasted quantity falls below the orderpoint's minimum quantity, a replenishment is incorrectly triggered.

**Why did this issue not occur in previous versions?** 
This behavior was introduced by [commit](https://github.com/odoo/odoo/commit/8ba2c1e38b636c567511139c5e19b7189430a182 ), which fixed the calculation of fresh(unexpired) quantity displayed in the stock availability widget on sales order lines.
Which expects that `scheduled_date` (typically the committed delivery date or expected delivery date, including leadtime) is passed to `read_qties` at [10] , which stores it in the context using the `to_date` key.

However, the same `to_date` key is also used by the orderpoint horizon-days logic. This overlap causes the expiration-aware quantity computation to use the horizon date instead of the intended `with_expiration` date , leading to incorrect forecast calculations and the unexpected replenishment behavior described above.

[1]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L394-L396 
[2]-https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L417-L427
[3]-
https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L374-L381
[4]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L484-L491 
[5]-
https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L386
[6]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L152-L154 [7]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L215-L218 [8]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L260-L262 [9]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L391 
[10]-
https://github.com/odoo/odoo/blob/afa2b6b7b47d6420146ceb6dad897405aa92c682/addons/sale_stock/models/sale_order_line.py#L129

## Solution
It does not make sense to trigger replenishment for perishable products solely because they are expected to expire before the  horizon date. Even when the available quantity already satisfies the maximum quantity defined on the reordering rule, the current logic forecasts those products as unavailable in advance of their expiration.

Instead, products should only be excluded from the forecast once they have actually expired, or when they must be removed according to the original expiration-handling logic.

To achieve this, an additional context key can be introduced to distinguish calls originating from the forecast availability widget from SO line. When the computation is performed for the forecast widget, the existing `to_date` context key should continue to be used so that availability is evaluated at the requested future date.

For all other flows, including orderpoint calculations, the system should rely on the `with_expiration` context key instead. This preserves the original behavior, where only already-expired quantities (or quantities that must be removed due to expiration rules) are excluded from availability calculations, preventing incorrect replenishment recommendations for perishable products.


opw-6200644

Forward-Port-Of: odoo/odoo#268223

**Issue**
Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse
can incorrectly update the remaining receipt quantity.

**Steps to reproduce**
- Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses)
- Create a PO for 35 units and confirm it
- Click on receive products, set received quantity to 10 and create a backorder
- Validate the next transfer
- Go back to the PO and change the quantity to 20
- Check the receipt demand
-> The backorder picking demand become 35 instead of 10

**Cause**
Updating the quantity of a purchase order line, also updates the related picking:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120
It updates the picking associated to the backorder since the other one is done:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197
This ultimately calls:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228
To compute the new demand for the picking, it retrieves the `move_dest`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240
To compute `qty_to_push`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249
However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking.
Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15`

**Solution**
The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand.
In push flows (e.g., multi-step receipts), this assumption does not hold. 
To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. 

**Additional information**
Known limitation: this does not address inconsistencies in return flows. When there're returns, units 
define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that.

opw-5512172

Forward-Port-Of: odoo/odoo#269666
Forward-Port-Of: odoo/odoo#248626

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

Forward-Port-Of: odoo/odoo#270416
Forward-Port-Of: odoo/odoo#265582

Currently when the user receives a perishable product that expires in future, it is considered for reordering regardless if the user has maximum quantity or not.

## Steps to produce:
- Install Inventory
- Go to settings > Enable 'Lots and Serial Numbers' and 'Expiration Dates'
- Create a product 'Vegetable Oil' that is tracked by lots.
- Enable Expiration date in the 'Inventory' Section and set Removal date to 2.
- Create a receipt for 'Vegetable oil' with Demand 10 and mark it as todo
- Details > Set 'Expiration Date' into the future > Set a Lot Number and Save
- Validate the receipt
- Open Product Form for Vegetable oil > Reordering Rules.
- Create a new Reordering rule with Min 5 and Max 10 and save.

## Observed Behavior:
The forecasted quantity is calculated as zero, resulting in a quantity to order of 10, even though no replenishment is actually required. The product already satisfies the maximum quantity defined on the reordering rule, and there is no existing demand, as there are no delivery orders or sales order reservations for the product.

**Why this is an issue:**
When the user navigates from the product form to the On Hand Quantity view to verify the stock situation, the forecasted quantity is shown as 10. This is inconsistent with the value displayed on the reordering rule, creating confusion and making it difficult to understand the actual inventory status.

In addition, if the product is configured with a Buy route, running the `Procurement: Run Scheduler` action repeatedly generates new purchase orders for the perishable product. Even if the generated purchase orders are cancelled or completed, since newly purchased stock will also have an expiration date. As a result, the same incorrect forecast calculation occurs again, causing the scheduler to continuously create new purchase orders and leading to an endless replenishment cycle if they expire within horizon days.

## Root cause:
When an orderpoint is created or updated, `_compute_qty_to_order` [1] is triggered. This method calls `_compute_qty_to_order_computed` [2] which accesses the forecasted quantity, causing its compute method to called.

The forecast computation retrieves context from `_get_product_context` as seen in [3], where the lead horizon date
(route lead time + horizon days configured in settings) is passed as `to_date` at [4]. It then reads the product's `virtual_available` quantity using the orderpoint context at [5].

This ultimately invokes `_compute_quantities`, which delegates the calculation of `virtual_available` to `_compute_quantities_dict`, as shown in [6].

As a result, `max_date` is set to the lead horizon date at [7] (for example, one year in the future). Since the product expires before that date, it is included in `expired_unreserved_quant_res`, causing `virtual_available` to be reduced to zero at [8].

Consequently, the forecasted quantity also becomes zero at [9]. Because the forecasted quantity falls below the orderpoint's minimum quantity, a replenishment is incorrectly triggered.

**Why did this issue not occur in previous versions?** 
This behavior was introduced by [commit](https://github.com/odoo/odoo/commit/8ba2c1e38b636c567511139c5e19b7189430a182 ), which fixed the calculation of fresh(unexpired) quantity displayed in the stock availability widget on sales order lines.
Which expects that `scheduled_date` (typically the committed delivery date or expected delivery date, including leadtime) is passed to `read_qties` at [10] , which stores it in the context using the `to_date` key.

However, the same `to_date` key is also used by the orderpoint horizon-days logic. This overlap causes the expiration-aware quantity computation to use the horizon date instead of the intended `with_expiration` date , leading to incorrect forecast calculations and the unexpected replenishment behavior described above.

[1]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L394-L396 
[2]-https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L417-L427
[3]-
https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L374-L381
[4]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L484-L491 
[5]-
https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L386
[6]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L152-L154 [7]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L215-L218 [8]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L260-L262 [9]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L391 
[10]-
https://github.com/odoo/odoo/blob/afa2b6b7b47d6420146ceb6dad897405aa92c682/addons/sale_stock/models/sale_order_line.py#L129

## Solution
It does not make sense to trigger replenishment for perishable products solely because they are expected to expire before the  horizon date. Even when the available quantity already satisfies the maximum quantity defined on the reordering rule, the current logic forecasts those products as unavailable in advance of their expiration.

Instead, products should only be excluded from the forecast once they have actually expired, or when they must be removed according to the original expiration-handling logic.

To achieve this, an additional context key can be introduced to distinguish calls originating from the forecast availability widget from SO line. When the computation is performed for the forecast widget, the existing `to_date` context key should continue to be used so that availability is evaluated at the requested future date.

For all other flows, including orderpoint calculations, the system should rely on the `with_expiration` context key instead. This preserves the original behavior, where only already-expired quantities (or quantities that must be removed due to expiration rules) are excluded from availability calculations, preventing incorrect replenishment recommendations for perishable products.


opw-6200644

Forward-Port-Of: odoo/odoo#268223

### Issue
Loading a large General Ledger (e.g., during an "Unfold All" action)
and retrieving display names for thousands of journal lines 
(`account.move.line`) causes excessive memory and performance overhead.

Profiling with `memray` showed that one of the main memory hotspots 
was located in `custom_label_builder`.

**Previous behavior:** Accessing `record.display_name` in a loop without
an explicit `fetch()` call triggered lazy computation of the field via
`_compute_display_name()`. When the compute method accessed stored
dependency fields (such as `name`, `ref`, `move_id`), each cache miss
went through `_fetch_field()`, which greedily loaded **all fields sharing
the same prefetch group** on the model, far beyond the dependencies of
`display_name` alone. This caused the ORM cache to be filled with many
unnecessary stored fields for every record in the prefetch set.

---

### Dataset Volume
The performance metrics were captured using a dataset consisting of:
* **455,694** Journal Items (`account.move.line`)
* **19,947** Journal Entries (`account.move`)

---

### Solution
Add a single `fetch(['display_name'])` call on the browsed recordset.
By calling `fetch(['display_name'])` upfront, the ORM goes through 
`_determine_fields_to_fetch(['display_name'])`, which walks
only the declared `field_depends` of `display_name` and fetches **only
those specific stored fields**. nothing more.

---

### Impact & Results

| Metric | Before Optimization | After Optimization | Change / Note |
| :--- | :--- | :--- | :--- |
| **Peak Memory** | ~856 MB | ~223 MB | ~74% reduction |
| **Execution Time** | 2.48s | 2.13s | About the same time with multiple tries |

OPW-6275158

Forward-Port-Of: odoo/enterprise#121020

a4efb745e9f4ba24dfa01f1e17e65f1a7cac90a5 merged the web_studio dynamic field and
the mass_mailing dynamic field into a single field selector,
included from the HTML editor.

This introduces a new flow where the user has to first "activate"
the field selector popover ( /field ), which appears as an overlay item;
then open the ModelFieldSelector dropdown to select a field on its
model, which appears as another overlay item.

As both overlay items overlap, and they have the same "z-index"
property, the last sibling in the overlay container appears first.

In mass_mailing, the ModelFieldSelector selector dropdown's overlay
item is introduced as the first child of that container; this results
in the dropdown appearing behind the item through which it was opened.

Fix: Overlay items holding a Dynamic Field Popover have their z-index
property reduced by 1, ensuring they appear behind their
ModelFieldSelectors at all times.

Steps to reproduce:
- Create a new mailing
- Add in any text node
- Type in /field
- Press Enter
- Click the [-] to select a field

task-5477951

**Issue**
Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application.

**Steps to reproduce**
- Activate by-product in the settings
- Create a product with an empty BOM (final product)
- Create another product tracked by serial number (by-product)
- Create and confirm a MO for the final product with 1 unit of the by-product
- Go to Miscellaneaous -> operation Type -> shopfloor
- Activate the option "Pre fill lot/serial numbers in shop floor"
- Return to the MO and open the shopfloor view
- Click on the '+' button next to the by-product and assign a serial number
- Try to close the production
-> A user error is raised stating that the by-product requires a serial number.

**Cause**
When the by-product is added manually on the MO, a stock move is created with an initial move line that does not contain any serial number.

Later, when assigning a serial number from the shopfloor view: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L121-L122 a new move line containing the serial number is created: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L116-L119 However, the original empty move line is not removed (the issue): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L124-L125 Because `self.picking_type_prefill_shop_floor_lots` is True, but `self.byproduct_id` is an empty recordset since: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1304-L1311 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1279 Indeed, `byproduct_id` is only populated from BOM-defined by-products. As a result, while confirming the production, there is 2 sml and among them, the original one without SN, which triggers the error:
https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L590 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L634-L635 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L658-L659 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L661-L669

opw-6223158

Forward-Port-Of: odoo/enterprise#118792

This commit does not bring native support for EPD on credit notes, only makes custom support a little easier and cleaner.

It is quite easy to support EPD (early payment discounts) on refunds by extending
- `_early_payment_discount_move_types`
- `_is_eligible_for_early_payment_discount`

However, this approach breaks when it reaches `inverse_tax_rep` in `_get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line`, which assumes tax repartition lines with `document_type == 'invoice'` and raises when called on `tax_rep` lines of 'refund' type instead.

This commit fixes that by selecting source and target repartition lines according to the `tax_rep`'s document type, which ensures:
- the `.index()` no longer raises a `ValueError`, as `tax_rep` is now looked up in the matching set (`refund_` for refunds, `invoice_` otherwise)
- `inverse_tax_rep` returns the corresponding line in the opposite set, preserving the original invoice->refund mapping while adding the refund->invoice one

Since `inverse_tax_rep` is a closure, downstream modules cannot patch it without copying the whole ~170-line method. Making it symmetric here lets custom EPD-on-refund support work without that duplication.

task-[6265601](https://www.odoo.com/odoo/all-tasks/6265601)

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

Forward-Port-Of: odoo/odoo#271102

This commit ensures product images follow their visual order in the
product image viewer when using the grid layout.

Steps to reproduce:
- Open a product page with multiple images (or add Extra Media to the 
  product)
- Change layout mode to "Grid" and click save
- Click any image to open the product image viewer
- Navigate between images

Images do not follow the visual left-to-right order. This regression was
introduced by [commit], which replaced the row-based grid with a
column-first layout. As a result, `querySelectorAll` returns images in
DOM order, which no longer matches the visual order.

To fix this, images are now reordered based on their visual placement in
the grid so navigation matches the order seen by the user. Images are
traversed in visual left-to-right order while also accounting for
varying image heights and multi-column alignment.

[commit]: https://github.com/odoo/odoo/commit/9a3628b9735550bf8ecc2252ea1b7338f68ab966
task-[4364143](https://www.odoo.com/odoo/project/974/tasks/4364143)

Forward-Port-Of: odoo/odoo#270732
Forward-Port-Of: odoo/odoo#254077

**Issue**
Printing an invoice for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print on the invoice 
-> The generated PDF displays "lot1 & lot2" instead of "lot1"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 2` since the invoice is on a quantity of 2 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic (as they should be): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80
- for the last one, `is_stock_return = False` while it should not, thus the quantity is 1 instead of 0. Furthermore, it does not pass by this code:
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/sale_stock/models/account_move.py#L79 which would make the quantity for lot2 equalled to 0 (1-1) The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 1, lot2: 0}`

The report selects both lots since it starts with lot1 (qty of 1): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6236855

Forward-Port-Of: odoo/odoo#270599

Issue
-----
There are 2 issues with USPS rest:

1. USPS packagings do not have their size UOM displayed. This leads to confusion as users input in inches but the dimensions are treated as feet.

2. USPS returns the same rate regardless of the package type.

Steps to reproduce
-----
- Set USPS up
	- Open the Package Type form > go to its' Dimensions tab

> Issue 1

- Set USPS up (domestic)
	- Select a `Domestic Rating Indicator` (eg LF - Flat Rate Box)
- Create a SO with some product
- Open the delivery widget and add a rate with USPS
	- Discard the changes
- Go to the delivery method and change the rating (eg SP - Single Piece)
- Go back to the SO
- Open the delivery widget and add a rate with USPS

> Issue 2, rate is the same as before

Issue 1
-----
By default, there is no displayed UOM on the form because of

https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/stock_delivery/models/stock_package_type.py#L20-L33

We can change this behaviour for USPS specifically as done in Envia

https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_envia/models/stock_package_type.py#L37-L46

Issue 2
-----
In `usps_rest_rate_shipment`, we request rates for every package of the delivery, which we receive as lists. We then iterate over the list to find the rate matching the `mail_class`. The problem is that this only filters over whether the delivery is domestic or international. We don't filter based on the actual service selected on the carrier (`usps_domestic_rating_indicator` for domestic and `usps_international_rating_indicator` for international).

https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_usps_rest/models/delivery_usps.py#L224-L236

-----
Ticket:
opw-6224918

Forward-Port-Of: odoo/enterprise#120789
Forward-Port-Of: odoo/enterprise#120594

A personal outgoing mail server is an `ir.mail_server` that belongs to one user. The
system only lets that user send through it. Mass mailings do not always respect this,
which can cause a few problems:

1. Admins cannot duplicate a personal server. The copy keeps the same owner, and the rule that says one user can own only one server stops the save.
2. In *Email Marketing > Settings*, the "Dedicated Server" picker offers every server, even personal ones. If an admin picks a personal one, all campaigns get stuck. The cron job runs as Odoobot, the personal server rejects it, and the mailing stays in the queue.
3. When no dedicated server is set, the fallback selection can still land on a personal server (for example because its `from_filter` matches the sender). The cron sends through it and gets rejected.


One commit per problem:

1. **mail**: duplicating a personal server now produces a copy with no owner.
2. **mass_mailing**: the picker in the settings hides personal servers. Setting an owner on a server that is already used for mass mailing now raises a clear error that names the campaign blocking the change.
3. **mass_mailing**: personal servers are skipped when the fallback selection runs, so only shared servers are considered.

opw-6086077

Forward-Port-Of: odoo/odoo#270607
Forward-Port-Of: odoo/odoo#261537

In the current code, for each slot, and for each "available"
resource, we check if the resource is available on the slot,
based on availability values. Then, we check the remaining
capacity of that resource. Also, linked resources information
is added when computing the original resource remaining capacity.
If many linked resources exist, this will be done several times
and is not useful.

This commit makes that loop disappear. We now check all resources
at once in terms of availability, and linked resources that could
be selected (in the appointment resources, in the slot resources
(if any restricted resource)) at the same time. Then, the total
capacity is the sum of the resource remaining capacity and the
ones of available linked resources.

Therefore, _slot_availability_is_resource_available is renamed to
_slot_available_resources, as it now takes more than one resource
and returns all resources among 'resources' that are valid on
the slot, based on the availability_values, slot restrictions and
booking lines.

A noticeable difference is mainly seen when using many resources
(and linked resources). For instance, a restaurant with a lot of
small tables will have their slot availability check much shorter.

BENCHMARK, LOCAL (time only, as number of requests does not change)
Only appointment installed

For a restaurant with
- 10 tables of 2
- 5 tables of 2 linked, 2 times
- 10 tables of 4
- 2 table of 2
- time then auto assign

On loading /appointment/id:
~ 3.1s -> ~ 1.6s
On selecting any number of people (1 to 10):
[2s, 2.5s] -> [0.6s, 0.8s]

Task-4144524

Forward-Port-Of: odoo/enterprise#121005
Forward-Port-Of: odoo/enterprise#107711

Steps to reproduce:
- Create a US company
- Go to Accounting > Configuration > Settings
- Activate `Avatax` > Set Credentials
- Try to "Sync Parameters"

Traceback:
```py
  File "/home/odoo/src/enterprise/saas-19.2/account_avatax/models/res_company.py", line 113, in avatax_sync_company_params
    'valid_country_ids': [(6, 0, get_countries(vals['validCountries']).ids)],
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/account_avatax/models/res_company.py", line 90, in get_countries
    return self.env['res.country'].browse([country_cache[code] for code in code_list])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5208, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```

The issue occurs because AvaTax return `*` in the `validCountries` field to indicate that an exemption code is valid for all countries. The synchronization logic stores this value in the country cache as `False` and later passes it to `res.country.browse()`. Since `browse()` does not accept a mix of valid IDs and falsy values, the operation crashes during the synchronization process.

This commit filter out falsy country IDs when resolving country codes to prevent crashes and allow exemption codes to be synchronized successfully.

opw-6298189

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

Version:
- 19.0

Steps to reproduce:
- Create a sign template with a readonly sign item linked to an auto field.
- Use a reference record where the linked field value is empty or False.
- Send the document for signing.
- Complete the signing flow.

Issue:
- Readonly sign items linked to auto-filled values could not properly handle
  falsy values. Empty values could trigger the error "Some required items are
  not filled" and completed sign requests displayed the sign item placeholder
  instead of the actual auto-filled value.
- completed document generation could fail when rendering falsy values for
  textarea sign items.

Cause:
- Falsy auto-filled values were ignored during constant item population and
  replaced by the sign item placeholder. Additionally, readonly constant items
  were included in required field validation and completed sign requests
  continued to display placeholders when the stored value was empty.
- document rendering assumed sign item values were always strings for textarea
  sign items but when auto field is empty it value can be False.

Fix:
- Preserve falsy values when populating readonly constant items, exclude
  constant items from signer validation, and hide placeholders for empty
  auto-filled constant items when displaying completed sign requests.
- Normalize falsy values to prevent crashes and allow completed documents
  to be generated correctly.

Forward-Port-Of: odoo/enterprise#121009

In POS, the Preparation Time report groups average preparation durations by hour. Those hour buckets were always computed with the timezone of the user who ran the module upgrade (OdooBot / superuser), not the timezone of the user viewing the report. Changing the user, company, or browser timezone had no effect on the graph until the module was upgraded again.

Steps to reproduce:
-------------------
* Configure a Preparation Display and create POS orders with measured preparation times.
* Open Point of Sale → Reporting → Preparation Time.
* Note the hour bucket used for the orders.
* Change your user timezone in Preferences and reload the report.

> Observation:
The hour buckets stay the same. Before the fix, they only changed after upgrading `pos_enterprise`, because the timezone was embedded in the SQL view created during `init()` as superuser.

Why the fix:
------------
Replace the static PostgreSQL view with a dynamic `_table_query` so `order_hour` is computed with the current user's timezone on each report read. `init()` now only drops the legacy view instead of recreating it with a frozen timezone.

opw-6220248

Forward-Port-Of: odoo/enterprise#118365

## Steps to reproduce

- Create an attribute A, of type always, with 2 values, one should have an extra price
- Create an attribute B, of type never, with 2 values
- Create a product that has both those attributes
- Create a combo with that product with both values for A
- Go to the PoS and order that combo with the value that has an extra price for A
- The extra price is added

## Why the fix:

For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo.

As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page.

It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always".

The variants are then considered as different products, as they should in this case.

If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it.

We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 

We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same.

opw-6262431

Forward-Port-Of: odoo/odoo#270625
Forward-Port-Of: odoo/odoo#268567

Currently when the user receives a perishable product that expires in future, it is considered for reordering regardless if the user has maximum quantity or not.

## Steps to produce:
- Install Inventory
- Go to settings > Enable 'Lots and Serial Numbers' and 'Expiration Dates'
- Create a product 'Vegetable Oil' that is tracked by lots.
- Enable Expiration date in the 'Inventory' Section and set Removal date to 2.
- Create a receipt for 'Vegetable oil' with Demand 10 and mark it as todo
- Details > Set 'Expiration Date' into the future > Set a Lot Number and Save
- Validate the receipt
- Open Product Form for Vegetable oil > Reordering Rules.
- Create a new Reordering rule with Min 5 and Max 10 and save.

## Observed Behavior:
The forecasted quantity is calculated as zero, resulting in a quantity to order of 10, even though no replenishment is actually required. The product already satisfies the maximum quantity defined on the reordering rule, and there is no existing demand, as there are no delivery orders or sales order reservations for the product.

**Why this is an issue:**
When the user navigates from the product form to the On Hand Quantity view to verify the stock situation, the forecasted quantity is shown as 10. This is inconsistent with the value displayed on the reordering rule, creating confusion and making it difficult to understand the actual inventory status.

In addition, if the product is configured with a Buy route, running the `Procurement: Run Scheduler` action repeatedly generates new purchase orders for the perishable product. Even if the generated purchase orders are cancelled or completed, since newly purchased stock will also have an expiration date. As a result, the same incorrect forecast calculation occurs again, causing the scheduler to continuously create new purchase orders and leading to an endless replenishment cycle if they expire within horizon days.

## Root cause:
When an orderpoint is created or updated, `_compute_qty_to_order` [1] is triggered. This method calls `_compute_qty_to_order_computed` [2] which accesses the forecasted quantity, causing its compute method to called.

The forecast computation retrieves context from `_get_product_context` as seen in [3], where the lead horizon date
(route lead time + horizon days configured in settings) is passed as `to_date` at [4]. It then reads the product's `virtual_available` quantity using the orderpoint context at [5].

This ultimately invokes `_compute_quantities`, which delegates the calculation of `virtual_available` to `_compute_quantities_dict`, as shown in [6].

As a result, `max_date` is set to the lead horizon date at [7] (for example, one year in the future). Since the product expires before that date, it is included in `expired_unreserved_quant_res`, causing `virtual_available` to be reduced to zero at [8].

Consequently, the forecasted quantity also becomes zero at [9]. Because the forecasted quantity falls below the orderpoint's minimum quantity, a replenishment is incorrectly triggered.

**Why did this issue not occur in previous versions?** 
This behavior was introduced by [commit](https://github.com/odoo/odoo/commit/8ba2c1e38b636c567511139c5e19b7189430a182 ), which fixed the calculation of fresh(unexpired) quantity displayed in the stock availability widget on sales order lines.
Which expects that `scheduled_date` (typically the committed delivery date or expected delivery date, including leadtime) is passed to `read_qties` at [10] , which stores it in the context using the `to_date` key.

However, the same `to_date` key is also used by the orderpoint horizon-days logic. This overlap causes the expiration-aware quantity computation to use the horizon date instead of the intended `with_expiration` date , leading to incorrect forecast calculations and the unexpected replenishment behavior described above.

[1]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L394-L396 
[2]-https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L417-L427
[3]-
https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L374-L381
[4]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L484-L491 
[5]-
https://github.com/odoo/odoo/blob/96b7eed9153eab60288d1624252df6f90ea9505e/addons/stock/models/stock_orderpoint.py#L386
[6]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L152-L154 [7]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L215-L218 [8]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/product.py#L260-L262 [9]-
https://github.com/odoo/odoo/blob/9ae1df190cf5ee6a5775eddb32be7b13f5ed92c9/addons/stock/models/stock_orderpoint.py#L391 
[10]-
https://github.com/odoo/odoo/blob/afa2b6b7b47d6420146ceb6dad897405aa92c682/addons/sale_stock/models/sale_order_line.py#L129

## Solution
It does not make sense to trigger replenishment for perishable products solely because they are expected to expire before the  horizon date. Even when the available quantity already satisfies the maximum quantity defined on the reordering rule, the current logic forecasts those products as unavailable in advance of their expiration.

Instead, products should only be excluded from the forecast once they have actually expired, or when they must be removed according to the original expiration-handling logic.

To achieve this, an additional context key can be introduced to distinguish calls originating from the forecast availability widget from SO line. When the computation is performed for the forecast widget, the existing `to_date` context key should continue to be used so that availability is evaluated at the requested future date.

For all other flows, including orderpoint calculations, the system should rely on the `with_expiration` context key instead. This preserves the original behavior, where only already-expired quantities (or quantities that must be removed due to expiration rules) are excluded from availability calculations, preventing incorrect replenishment recommendations for perishable products.


opw-6200644

Forward-Port-Of: odoo/odoo#268223

This commit does not bring native support for EPD on credit notes, only makes custom support a little easier and cleaner.

It is quite easy to support EPD (early payment discounts) on refunds by extending
- `_early_payment_discount_move_types`
- `_is_eligible_for_early_payment_discount`

However, this approach breaks when it reaches `inverse_tax_rep` in `_get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line`, which assumes tax repartition lines with `document_type == 'invoice'` and raises when called on `tax_rep` lines of 'refund' type instead.

This commit fixes that by selecting source and target repartition lines according to the `tax_rep`'s document type, which ensures:
- the `.index()` no longer raises a `ValueError`, as `tax_rep` is now looked up in the matching set (`refund_` for refunds, `invoice_` otherwise)
- `inverse_tax_rep` returns the corresponding line in the opposite set, preserving the original invoice->refund mapping while adding the refund->invoice one

Since `inverse_tax_rep` is a closure, downstream modules cannot patch it without copying the whole ~170-line method. Making it symmetric here lets custom EPD-on-refund support work without that duplication.

task-[6265601](https://www.odoo.com/odoo/all-tasks/6265601)

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

Forward-Port-Of: odoo/odoo#271102

**Steps to reproduce:**
- make sure your main company (company 1)
has dollars as its main currency
- create second company (company 2) and a 
warehouse in this second company
- set euro has the main currency in the company 2

From company 1:
-  set an exchange rate 
of 1$ = 0.5 eur on the euro currency
- create a storable product with a cost of 10$
and an on-hand quantity of 1

From company 2: 
- set the cost to 10 eur and set an on-hand
quantity of 1

with both company selected and company 1 
as the main company selected: 
- open the stock view and look for your product

**Current behavior:**
the total value is 20$

**Expected behavior:**
with conversion rate, it should be 
30$

**Cause of the issue:**
when computing the total value 
we do not apply a conversion rate from 
the value of the company to the main 
company selected
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/stock_account/models/product.py#L273

opw-6280108

Forward-Port-Of: odoo/odoo#270575

### Issue
Loading a large General Ledger (e.g., during an "Unfold All" action)
and retrieving display names for thousands of journal lines 
(`account.move.line`) causes excessive memory and performance overhead.

Profiling with `memray` showed that one of the main memory hotspots 
was located in `custom_label_builder`.

**Previous behavior:** Accessing `record.display_name` in a loop without
an explicit `fetch()` call triggered lazy computation of the field via
`_compute_display_name()`. When the compute method accessed stored
dependency fields (such as `name`, `ref`, `move_id`), each cache miss
went through `_fetch_field()`, which greedily loaded **all fields sharing
the same prefetch group** on the model, far beyond the dependencies of
`display_name` alone. This caused the ORM cache to be filled with many
unnecessary stored fields for every record in the prefetch set.

---

### Dataset Volume
The performance metrics were captured using a dataset consisting of:
* **455,694** Journal Items (`account.move.line`)
* **19,947** Journal Entries (`account.move`)

---

### Solution
Add a single `fetch(['display_name'])` call on the browsed recordset.
By calling `fetch(['display_name'])` upfront, the ORM goes through 
`_determine_fields_to_fetch(['display_name'])`, which walks
only the declared `field_depends` of `display_name` and fetches **only
those specific stored fields**. nothing more.

---

### Impact & Results

| Metric | Before Optimization | After Optimization | Change / Note |
| :--- | :--- | :--- | :--- |
| **Peak Memory** | ~856 MB | ~223 MB | ~74% reduction |
| **Execution Time** | 2.48s | 2.13s | About the same time with multiple tries |

OPW-6275158

Forward-Port-Of: odoo/enterprise#121020

**Issue**
Printing an invoice for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print on the invoice 
-> The generated PDF displays "lot1 & lot2" instead of "lot1"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 2` since the invoice is on a quantity of 2 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic (as they should be): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80
- for the last one, `is_stock_return = False` while it should not, thus the quantity is 1 instead of 0. Furthermore, it does not pass by this code:
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/sale_stock/models/account_move.py#L79 which would make the quantity for lot2 equalled to 0 (1-1) The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 1, lot2: 0}`

The report selects both lots since it starts with lot1 (qty of 1): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6236855

Forward-Port-Of: odoo/odoo#270599

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#120592
Forward-Port-Of: odoo/enterprise#118031

The following error is raised in the POS when paying with an Adyen terminal:
```
TypeError: Cannot read properties of undefined (reading 'uuid')
at Proxy.handleAdyenStatusResponse
```

Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes.

opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference.

Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch.

opw-6237987

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

Forward-Port-Of: odoo/odoo#270880
Forward-Port-Of: odoo/odoo#269720

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#119747
Forward-Port-Of: odoo/enterprise#118031

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#119747
Forward-Port-Of: odoo/enterprise#118031

Currently, resources are either entirely strict (bound by fixed start/end intervals) or entirely flexible. There is no native way to support a hybrid calendar where an employee has specific days that are flexible (duration-based) and other days that are strict.

This commit introduces "duration-based" scheduling, allowing the system to bypass strict time intersections on specifically flagged days while maintaining a strict capacity cap.

Changes include:
- `resource.resource`: Added `_is_duration_based(start_dt, end_dt)` helper to dynamically identify if a resource has flexible attendance within a specific date range or single day.
- `planning.slot`:
  - `auto_plan_ids`: Expanded the bulk interval fetch for hybrid resources to prevent the core HR module from clipping flexible days, and implemented a day-by-day intersection bypass inside the `find_resource` allocation loop.
  - `_get_working_hours_over_period`: Intercepted manual shift calculations. If a shift falls on a duration-based day, it bypasses the strict `work_intervals` overlap and assigns the literal shift duration (safely capped at the employee's daily capacity). Timezone-aware date conversions ensure accuracy.
  - `_gantt_unavailability`: Filtered out grey unavailability blocks on duration-based days so the Gantt chart accurately reflects flexible placement.

Task-ID: 6285642

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101

Forward-Port-Of: odoo/odoo#268504

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Step to reproduce:
- install purchase, pos_sale
- from setting enable mto route and ship later feature for pos
- from routes, unarchive mto route
- create a product, add mto and buy route, add a vendor
- create a SO with that product, qty  = 5
- open that quotation in pos and fulfill the order, set ship later date
- go to backend and open purchase

Observation:
- purchase qty is 10

Cause:
- the procurement for the order is created 2 times
- once from `_launch_stock_rule_from_pos_order_lines`
https://github.com/odoo/odoo/blob/0b17840fb3cc72935e1a6302a057fb55c253c498/addons/point_of_sale/models/pos_order.py#L1185-L1191
- again from `_action_launch_stock_rule`
https://github.com/odoo/odoo/blob/0b17840fb3cc72935e1a6302a057fb55c253c498/addons/sale_stock/models/sale_order.py#L180-L182

- later as vendor is same, both procurements are merged and PO quantity is updated to 10

Fix:
- we skip the procurement trgger from `_action_launch_stock_rule` when confirming the sale order

Note: After this fix, SO will not have a PO linked to it, as the SO is now transfered to pos, we have to go to pos and fulfill the delivery there.

opw-6259660

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

### Summary

When `dev_mode` includes `reload`, the `ThreadedServer` FSWatcher triggers a phoenix
restart by sending the process a `SIGHUP`, and `signal_handler` turns `SIGHUP` into
`KeyboardInterrupt`. `ThreadedServer.run()` only catches that in its wait-loop — but
there are two windows where the `KeyboardInterrupt` is raised **outside** the
`try/except`, escapes `run()`/`main()`, and exits the interpreter with code **130**.
Under Docker's default `restart: no`, PID 1 dies and the container does not come back.

1. **Startup** — a `SIGHUP` during `self.start() + preload_registries()` (e.g. a save
   while a previous reload is still loading modules).
2. **Teardown / duplicate** — a single save often emits two FS events; the FSWatcher's
   `if not odoo.phoenix:` dedup races across threads and fires two `SIGHUP`s. The first
   begins the phoenix teardown; the second lands during `self.stop()` / `_reexec()`,
   outside the guarded region, and escapes the same way.

### Reproducer (deterministic)

Boot a threaded server and signal it a few times in quick succession:

```bash
odoo-bin -d <db> --workers 0          # ThreadedServer
# once it is up, with <pid> = the odoo process:
for i in $(seq 8); do kill -HUP <pid>; sleep 0.12; done
```

Unpatched the process exits **130**; patched it survives after a single clean phoenix
reload. The same happens from a single editor save (duplicate FS events) or a bulk
file change.

### Fix

Two guards in `signal_handler`, plus bracketing the startup window in `run()`:

- **Startup**: a module flag marks the `self.start() + preload_registries()` window; a
  `SIGHUP` arriving then is *deferred* (recorded, not raised). After the window `run()`
  replays its effect inline so the wait-loop performs the normal phoenix restart.
- **Duplicate**: if `odoo.phoenix` is already set a restart is already in flight, so a
  further `SIGHUP` is redundant and is ignored rather than raised.

`SIGINT`/`SIGTERM` are untouched — `Ctrl-C` and `docker stop` keep working unchanged.
The fast path (no `SIGHUP`) is one flag set + one clear per startup.

### Notes

- Targeted at **17.0** (oldest affected branch) for forward-porting. The 17.0 → 18.0
  hop will conflict: on 18.0/master the flag is the module-level `server_phoenix` global
  and `run()` wraps the critical section in `with Registry._lock:`. I'll resolve the
  forward-port.
- Prior art: #21209 (introduced the phoenix flag), #206898 (graceful reload), #207930.
- CLA: signed via #269075 (Codeforward corporate CLA).