Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#99831
Forward-Port-Of: odoo/enterprise#98983

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

Forward-Port-Of: odoo/enterprise#99073

# How to reproduce the issue:
- Create two currency rates: one for today and one for the day before.
- Create two invoices with different `amount_total`, both using the rate from yesterday.
- Create a group payment dated today.

Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices.

Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed.

It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`.

In a group payment scenario:
- Two partials are created (one per invoice).
- Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line).
- As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment.

opw-5147281

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

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Forward-Port-Of: odoo/enterprise#98545

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 20 hours)
4. Open the project dashboard and check the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard and check the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
-------
After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234


**Before**
Case 1: Encoding method = Hours/Minutes
Consider allocated_hours = 80 Hours,
total_timesheet_time = 20 Hours

Then:
uom_ratio = 1/1 => 1
allocated = 80/1 => 80 Hours
effective = 20/1 => 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
Consider allocated_hours = 80 Hours,
total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it)

Then:
uom_ratio = 1/8 => 0.125
allocated = 80/.125 => 640 Days
effective = 2/0.125 => 16 Days --> INCORRECT

**After**
Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method)
and total_timesheet_time = 2 Days (already in days, no conversion).

Then:
uom_ratio = 1/8 => 0.125
allocated = 80*.125 => 10 Days
effective = 2 => 2 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related enterprise PR: https://github.com/odoo/enterprise/pull/98545





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

Forward-Port-Of: odoo/odoo#233803

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#235502
Forward-Port-Of: odoo/odoo#225014

**Issue:**

Non-admin users get an AccessError as follows

```doesn't have 'create' access to: - Default Values, Based on (Purchase Order Suggest) (ir.default: 45)... ```

when using the Purchase Order Suggest wizard.

**Cause:**

The `ir_default_user_rule` record rule restricts non-admin users to only create/modify ir.default records where
  `user_id = user.id`

However,  in  `_save_values_for_vendor` method:

https://github.com/odoo/odoo/blob/6b8a8196c63275eead6709bb20002df0be12a059/addons/purchase_stock/wizard/purchase_order_suggest.py#L199-L204

 `ir.default.set()`  is called without setting the `user_id` parameter, which defaults to an attempt to create a global default: what only admins can do.

**Steps to reproduce:**

- create a non-admin user with purchase user permissions.
- log  in as that user and create a Purchase Order
- add products to the catalog and click "Suggest.
- configure suggest parameters and click "Compute" (Note: compute is only enabled when estimated_price > 0)

An AccessError occurs

opw-5076647

Forward-Port-Of: odoo/odoo#227643

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Forward-Port-Of: odoo/enterprise#98545

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 20 hours)
4. Open the project dashboard and check the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard and check the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
-------
After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234


**Before**
Case 1: Encoding method = Hours/Minutes
Consider allocated_hours = 80 Hours,
total_timesheet_time = 20 Hours

Then:
uom_ratio = 1/1 => 1
allocated = 80/1 => 80 Hours
effective = 20/1 => 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
Consider allocated_hours = 80 Hours,
total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it)

Then:
uom_ratio = 1/8 => 0.125
allocated = 80/.125 => 640 Days
effective = 2/0.125 => 16 Days --> INCORRECT

**After**
Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method)
and total_timesheet_time = 2 Days (already in days, no conversion).

Then:
uom_ratio = 1/8 => 0.125
allocated = 80*.125 => 10 Days
effective = 2 => 2 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related enterprise PR: https://github.com/odoo/enterprise/pull/98545





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

Forward-Port-Of: odoo/odoo#233803

Steps to reproduce:
===================
1- Website app > Open any page in Edit mode.
2- Drag a Video block into the page.
3- Paste a Vimeo video URL in the dialog and save. 
4- Save the page, then re-open it in Edit mode.
-> traceback

Cause:
======
The Wysiwyg "openMediaDialog" passes the selected media DOM node as "media" to the MediaDialog.
The MediaDialog forwards that value as "media" prop to VideoSelector. VideoSelector declared "media" as "{ type: Object, optional: true }". Owl validates "type: Object" as a plain object, not as any "typeof object".
DOM elements such as HTMLImageElement do not pass this plain object check, so Owl raises an error.

Solution:
=========
Relax the "media" prop type in VideoSelector so DOM nodes are accepted. In web_editor VideoSelector, change the "media" prop to "{ optional: true }".
In html_editor VideoSelector, also keep "media" declared as "{ optional: true }".

opw-5239889

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

Forward-Port-Of: odoo/odoo#236296

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#235502
Forward-Port-Of: odoo/odoo#225014

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

Forward-Port-Of: odoo/enterprise#99073

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

Steps to reproduce:
- Enable Analytic Accounting.
- Assign a project A to User A.
- Create user B with Manufacturing User + Timesheet User rights.
- Create a storable product “P1” with the following BoM:
    - Component: 1 unit of C1
    - Workorder: Operation of 60 minutes
    - Project: Project A
- As user B:
- Create a mo to produce one unit of “P1”
    - confirm the MO
    - start the workorder and try to mark it as done.

Issue:
An access error is raised when creating analytic lines:
"Sorry 'user B' doesn't have read access to account.analytic.line"

Explanation:
Since the project is assigned to Mitchell Admin and not to Marc Demo,
the access rule below applies:
https://github.com/odoo/odoo/blob/19.0/addons/hr_timesheet/security/hr_timesheet_security.xml#L50-L62

Because Marc Demo belongs to the "Timesheet User" group but not to
the "Accounting" group, he lacks the required access rights,
which triggers the analytic line read restriction.

opw-5262213

Forward-Port-Of: odoo/enterprise#99716

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#99842
Forward-Port-Of: odoo/enterprise#96122

[FIX] html_builder, website: allow user to translate a field

Steps to reproduce the problem:
- With french installed on a website, go to `/fr/shop`.
- Enter in translate mode.

-> You can not edit product names.

The problem is that since [1], regular fields are not translatable. This
commit does two things:
- It modifies the `o_editable_selectors` selector in edit mode to allow
translation of regular fields.
- Because we revert the logic of [1], the problem that was solved by
this commit (translation of a mega menu item) still has to be fixed. To
do so, the `o_editable` or `o_editable_attribute` is removed when
setting the `data-oe-readonly` attribute on cascaded branded elements.
The idea is to follow the same logic than in the `SetupEditorPlugin`
where elements with the `data-oe-readonly` attribute are filtered before
adding the `o_editable` class.

task-5265949

[1]: https://github.com/odoo/odoo/commit/d4d428ff1d5be46135973aa806f206a1076bfcf7

Forward-Port-Of: odoo/odoo#235800

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key.

BEFORE:
Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC)

NOW:
Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour.  

Note:
I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4
as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different)

task#4629641

Forward-Port-Of: odoo/enterprise#99855
Forward-Port-Of: odoo/enterprise#93841

# How to reproduce the issue:
- Create two currency rates: one for today and one for the day before.
- Create two invoices with different `amount_total`, both using the rate from yesterday.
- Create a group payment dated today.

Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices.

Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed.

It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`.

In a group payment scenario:
- Two partials are created (one per invoice).
- Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line).
- As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment.

opw-5147281

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

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

Forward-Port-Of: odoo/enterprise#99073

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#99842
Forward-Port-Of: odoo/enterprise#96122

Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions:
- sign.template with signature/initials fields and more than one role
- more than one sign user (internal user)

```
  File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 341, in _compute_only_autofill_readonly
    not (item.type_id.name == 'Signature' and request._get_user_signature(user, 'sign_signature')) and
                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 323, in _get_user_signature
    return user[signature_type]
           ~~~~^^^^^^^^^^^^^^^^
  File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 6680, in __getitem__
    return self._fields[key].__get__(self)
           ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/fields.py", line 1646, in __get__
    record._check_field_access(self, 'read')
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 3426, in _check_field_access
    raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
```
This commit ensure that we don't try to access the signature/initial field of another user when it is not necessary.

task-5271648

Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Forward-Port-Of: odoo/enterprise#98545

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 20 hours)
4. Open the project dashboard and check the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard and check the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
-------
After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234


**Before**
Case 1: Encoding method = Hours/Minutes
Consider allocated_hours = 80 Hours,
total_timesheet_time = 20 Hours

Then:
uom_ratio = 1/1 => 1
allocated = 80/1 => 80 Hours
effective = 20/1 => 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
Consider allocated_hours = 80 Hours,
total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it)

Then:
uom_ratio = 1/8 => 0.125
allocated = 80/.125 => 640 Days
effective = 2/0.125 => 16 Days --> INCORRECT

**After**
Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method)
and total_timesheet_time = 2 Days (already in days, no conversion).

Then:
uom_ratio = 1/8 => 0.125
allocated = 80*.125 => 10 Days
effective = 2 => 2 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related enterprise PR: https://github.com/odoo/enterprise/pull/98545





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

Forward-Port-Of: odoo/odoo#233803

This PR consolidates multiple fixes and improvements across **account**, **sale_management**, and **sale** to make the section widget more internally consistent.
It addresses visibility rules, optional section logic, resequencing behavior, and some configurator quirks.

---

### **1. Section Widget: Hide Prices / Hide Composition Logic**

* Subsections under a hidden section now correctly disable both *Hide Prices* and *Hide Composition*.
* Subsections under a *Hide Prices* section cannot hide prices, but may still hide composition.
* Mutually exclusive states: a section cannot have *Hide Prices* and *Hide Composition* active at the same time.
* Resequencing a subsection under a *Hide Composition* section resets all its state flags.
* Removed confusing buttons:

  * “Add a Section” inside a section
  * “Add a Subsection” inside a subsection

---

### **2. Optional Section Behavior (sale_management)**

* Optional sections and subsections cannot activate *Hide Prices* or *Hide Composition*.
* Subsections under a *Hide Prices* section cannot hide prices or become optional (but can hide composition).
* Resequencing into a section with *Hide Composition* resets all child states to `false`.
* New lines inside optional sections default to quantity **0**.
* Setting a section as optional resets all nested `collapse_*` states.

---

### **3. Resequencing Logic for Optional Sections**

Improved behavior when moving sections and lines:

* **Quantity rules**

  * Moving a line **into** an optional section → qty → `0`
  * Moving a line **out** of an optional section → qty → `1`
  * Same logic applies when moving entire sections that change which lines fall under them.

* **Recalculation rules**

  * Moving a section **up**:

    * Recompute all lines under the moved section.
    * Recompute all lines between old/new positions.
  * Moving a section **down**:

    * Recompute all lines under crossed sections.
    * Recompute all lines between old/new positions (excluding overlaps).

---

### **4. Combo Line Move Fix (sale)**

* Unsaved combo lines were missing *Move Up/Down* due to `virtual_id` not being considered.
* Updated logic to include `linked_virtual_id` so combos can be moved even when unsaved.

---

### **5. Other Fixes**

* Made dynamic conditional labels translatable (Hide/Show Prices, Hide/Show Composition, Set/Unset Optional).
* Updated the relevant XPath introduced in earlier commits.
* Removed an archived product from quotation template demo data.
* Added mobile UI controls for section toggles (`collapse_prices`, `collapse_composition`, `optional`).
* Configurator adjustments for optional-section products:

  * Hide quantity controls, price, and total.
  * Added products default to qty `0` inside optional sections.


See Also:
- https://github.com/odoo/enterprise/pull/99188

task-5082193

### Issue:

Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.

### Steps to reproduce:
- Create a kit product with a kit BOM:
    - 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation

### Cause of the issue:

Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does,  the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921

### Fix:

In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.

opw-5100026

Forward-Port-Of: odoo/enterprise#99845
Forward-Port-Of: odoo/enterprise#98589

**Steps to reproduce:**

1- Install the purchase_stock module.
2- Create a new PO with a new vendor.
3- Add new one product in the purchase order line with quantity > 1.
4- Confirm the PO and go to the generated receipt.
5- Validate the receipt with less than the ordered quantity, by choosing no
   backorder.
6- Duplicate the receipt for the remaining quantity and validate it.
7- In vendor form view, the On-time Rate value shown in the smart button differs
   from the value in the graph.

**Issue:**
https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42

- The On-time Rate shown in the smart button does not match the graph.

**Example:**

- PO Line ordered qty: 10  
- First receipt validated: 6 (no backorder)  
- Duplicated receipt validated: 4  
- In vendor form view inside On-time Rate Smart button
- Total quantity coming: 14 (incorrect)  
- Expected total qty for calculation: 10 (from PO line)  
- On-time delivery rate calculated: **71.43%**  
- Expected On-time delivery rate: **100%**

**Cause:**

- The report uses `product_qty` from the stock move.  
- When a receipt is duplicated and the demand quantity is manually set, 
`product_qty` is recomputed from this demand value.  
This leads to a mismatch between the PO line quantity and the aggregated stock 
move quantities.

**NOTE:**
In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line::
`purchase_order.order_line.flush_recordset()`

- Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field.
- The computed value first lives in Odoo’s cache.
- It is not written to the database until a flush occurs.
- If we immediately call something like _read_group() (which queries the database directly), 
it won’t see the cached value — only what is persisted in the DB.

**Solution:**

- Use the purchase order line quantity instead of the stock move’s `product_qty` 
to ensure consistent and accurate On-time Rate calculation.

opw-4991367