# Description of the issue/feature this PR addresses:

From saas-18.3 onward, the pos_settle_due module introduced a new method to identify settlement lines. 
While the old method **isSettleDueLine()** is still there, 
the new **isAnySettleLine()** covers both order settlement and invoice settlement. 

This change was not reflected in the Saudi POS EDI integration during forward-porting,
which caused incorrect validation when processing POS orders containing both
regular sale lines and settlement lines.

# Current behavior before PR:

- Orders containing a mix of new sale lines and settlement lines could bypass
the intended validation.

- The validation logic relied on the old isSettleDueLine() method

# Desired behavior after PR is merged:

- Update the validation flow to use isAnySettleLine() (when available) to
correctly detect settlement lines.

- Prevent validation of POS orders that contain both settlement lines and new
sale lines.

- Ensure compatibility with newer versions of the pos_settle_due module and
restore the intended settlement validation behavior.

- Test case to ensure no regression on this feature

I confirm I have signed the CLA and read the PR guidelines at
[www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/odoo#254275

Steps to reproduce:
--------------------------
1. Install sale_timesheet
2. Create a quotation with a timesheet-based product
   - Set quantity = 3
   - Set UoM to Days (timesheet UoM is Hours)
3. Confirm the quotation and click on the smart button Recorded.
4. Record 16 hours of timesheets.
5. Create an invoice using a timesheet period (starting from SO date)
6. Check the invoice quantity

Issue:
-----------
The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours).

Cause:
-----------
After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied.

Solution:
---------------
Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice.

opw-6024804





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

Forward-Port-Of: odoo/odoo#255790
Forward-Port-Of: odoo/odoo#254273

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

Forward-Port-Of: odoo/odoo#255601
Forward-Port-Of: odoo/odoo#254618

### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
  "Ecuador" → "ECUADOR").
- Upgrade the module.

### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").

During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:


```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
    convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
    raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'

 select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id  | name                                                                 | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE   |
+-----+----------------------------------------------------------------------+------+
```


### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.

### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador

Using XMLIDs ensures consistent resolution regardless of name changes
or translations.

opw-6015302
upg-3950261
tbg-2492

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#256029
Forward-Port-Of: odoo/odoo#254096

**Steps to reproduce:**
- Open the PoS
- Select a combo and choose whatever
- Use the numpad or keyboard to set the combo's qty to 10
- Choose another customer or preset
- The price is all wrong

**Why the fix:**
Whenever we change the customer or the preset, the **setPriceList** function is triggered. In this
function we recompute the combo's children lines' price.

Before this commit, we assumed that the combo's parent line's qty would always be one, and the logic was written on this assumption. Meaning that when it's manually changed, the data is wrong. What really happens is that most of the children line's qty end up being treated as an extra price.

This happens because in our exemple, the parent and children lines have a qty of 10, but we only set the free qty based on the assumption that the parent line has a qty of 1 on those lines https://github.com/odoo/odoo/blob/f5d5783b6a0c908127aa620ad0ec5b0008d7adf4/addons/point_of_sale/static/src/app/models/pos_order.js#L482-L485

This means that, as the free qty is rapidly depleted, we fall back on the extra products, and their unit price end up becoming the combo's base_price.

We now set the right amount in the free qty based on the parent line's qty.

When doing this, another problem arises, we have to multiply the children's unit price by the parent's qty, as theunit price's computation was based on the fact that weonly have a qty of one on the parent line.
This is because we were still basing the unit_price the the parent's lstPrice, but this price was not using the parent's qty at all, so we need to multiply it by the parent line's qty to make it work.

The unit price handling has to be done in the **computeComboItems** function, as we also need to adjust the remaining price accordingly. An access to the parent's qty was added onto the child line, to avoid adding a default parameter to the function, which should be avoided in stable if possible.


opw-5266483

Forward-Port-Of: odoo/odoo#244940

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/819c58ed50 [REL] 18.4.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/14a0b8049f [FIX] grid_renderer_store: keep wrapping width with explicit align [Task: 6032407](https://www.odoo.com/odoo/2328/tasks/6032407)
https://github.com/odoo/o-spreadsheet/commit/54b793736a [FIX] functions: stop debugging context [Task: 6052128](https://www.odoo.com/odoo/2328/tasks/6052128)
https://github.com/odoo/o-spreadsheet/commit/af564146ba [FIX] config: fix release flow [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c28bc91904 [FIX] SheetView: dirtify sheet viewport at UPDATE_CELL [Task: 5953775](https://www.odoo.com/odoo/2328/tasks/5953775)
https://github.com/odoo/o-spreadsheet/commit/1668f60184 [FIX] xlsx: do not export dynamic tables to excel [Task: 5214240](https://www.odoo.com/odoo/2328/tasks/5214240)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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

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

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

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

task-6051549

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

Forward-Port-Of: odoo/enterprise#111835
Forward-Port-Of: odoo/enterprise#111108

**Steps to reproduce:**
* Install the `quality_control` module.
* Create a storable product.
* Configure a Quality Control Point:
  * Set Control per : Quantity.
  * Set Operation Type to Receipts.
  * Set Product to the created product.
* Create a Receipt for the product with a demand of  5 units.
* Confirm the receipt and mark it as To Do.
* Click on the Quality Check button.
* Click on Fail and set the failed quantity to 3.
* Click on Confirm.

**Observed behavior:**
* A new stock move is created for the failed quantity.
* The original move is split incorrectly:
  * First move: 2 `product_uom_qty` and 2 `quantity`.
  * Second move: 2 `product_uom_qty` and 3 `quantity`.
* The failed move has a demand of **2** instead of **3**.

**Cause:**
* Clicking on *Quality Check* triggers `check_quality`, 
which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82
* Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88
* Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97
* In `_move_line_to_failure_location`, a new stock move 
is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480
* The demand quantity is computed using the minimum of the 
failed quantity and the move line quantity.
* This leads to an incorrect demand of *2* instead of *3*.
* However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472

**Fix:**
* Ensure that partial failures properly split stock moves with 
correct `product_uom_qty` and `quantity` values.

---

opw-5492095

Forward-Port-Of: odoo/enterprise#112125
Forward-Port-Of: odoo/enterprise#107493