Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#116593
Forward-Port-Of: odoo/enterprise#115100

### Issue before this commit:
The XML export for branch companies incorrectly identified the branch as the sender, even when a Peppol parent company was configured.

### Steps to reproduce the issue:
1. Download Accounting, Contacts and l10n_be
2. Create a branch for a Belgium company
3. Enable Peppol sending on the parent company
4. Enable Peppol sending on the branch company using the parent company endpoint
5. Switch to branch company
6. Create a customer invoice in the branch company using a customer who is on the Peppol network (meaning insert a valid VAT number and then verify button in the Accounting tab)
7. Confirm and send the invoice via Peppol
8. Download the resulting xml file and check the "AccountingSupplierParty" nodes. It contains the data of the branch and not the ones of the parent company

### Cause of the issue:
The EDI export logic was fetching the supplier data directly from the invoice's company record without checking for a delegated Peppol parent company, ignoring the hierarchical relationship defined in the settings.

### Reason to introduce the fix:
This fix ensures that the AccountingSupplierParty in the UBL/CII file correctly reflects the parent company's data when applicable.

opw-6030526

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

Forward-Port-Of: odoo/odoo#260389

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

**Steps to reproduce:**
1- Create a new PO/SO/Invoice.
2- Add a new order line and select a product.
3- Click on the UI dropdown to hide the Product column/field.
4- In the Description column (stored as name in the model), the product name appears by default. Delete it and write a manual description.
5- Enable the Product column once again.

**Issue:**
The description no longer appears under the product name in the form view

**Why this happens:**
Commit https://github.com/odoo/odoo/commit/bd5b86e1596e0058ff8f46a79b7c1a918f1d4adc introduces the new logic below:
`this.currentProductName = this.productName ? label.split("\n")[0] : "";`
which assumed the label will always come from the backend in the form [Product Name] + [Product Translation]
So when the following condition was checked, it evaluated to true and the description was truncated:
`else if(this.currentProductName && label.startsWith(this.currentProductName))`

However, a customer can manually edit the description like mentioned above, removing the product name from the description (`name`) column.

Additionally, the fix affected another flow. When you create a product with a Vendor Product Name/Code for vendor X and then create a RFQ for vendor X with that product, the Vendor Product Name/Code no longer appears in the description.

**Resolution:**
Since the fix for the initial problem is causing significant side effects across multiple flows, we decided to revert
the fix.

opw-6189252

Forward-Port-Of: odoo/odoo#263305

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

**Issue:**
In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear. The navbar remains stuck in mobile mode even when there is enough space to display the full layout.

**Fix:**
The navbar was relying on `env.isSmall`, which is only set during initialization and does not react to window resizing. This has been updated to use `this.ui.isSmall`, which is reactive and updates dynamically when the viewport size changes.

**Before:**
After resizing from mobile to a larger width, the navbar continued to behave as if it were still in mobile view, keeping menu items and the app icon hidden.

**After:**
When the screen width increases, the navbar correctly detects the change and re-renders, restoring the menu items and app icon as expected.

opw-6107660

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

Forward-Port-Of: odoo/odoo#263482
Forward-Port-Of: odoo/odoo#263039

**Steps to Reproduce:**

1. Click on configure on one of the job positions having a recruiter assigned.
2. Remove the recruiter from the form
3. Now try to go to Settings App > Manage Users. (You will stuck with an error) 
4. Navigate to users using the menu, and open Mitchell Admin → He is no longer an employee.

**Bug Cause:**
In HrJob.write(), when recruiter_id changes, the code attempts to update ongoing applications' recruiter by writing:
    application_ids.recruiter_id.user_id = job.recruiter_id.user_id

This traverses the relational chain and writes user_id directly on the existing recruiter employee record instead of reassigning the recruiter on the applications. When recruiter_id is cleared, job.recruiter_id.user_id resolves to False, effectively setting user_id = False on the previous recruiter's hr.employee record, breaking the link between the employee and their user account.

**Bug Solution:**
Directly reassign recruiter_id on the ongoing applications instead of mutating the employee's user_id: application_ids.recruiter_id = job.recruiter_id

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

Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#116593
Forward-Port-Of: odoo/enterprise#115100

### Steps to reproduce:

- In the settings Enable: "Multi-Steps Routes"
- Unarchive the MTO route
- Create a storable product with MTO enabled and a set vendor
- Create and confirm two sale orders for 1 unit of that product
- Go to the purchase order view, select both PO > Actions > Merge RFQs
#### > The un-cancelled Purchase order is  only linked to one of the 2 SOs

### Cause of the issue:

The sale orders linked to a PO in this flow are linked through the stock references:
https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase/models/purchase_order.py#L60-L61 https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase_stock/models/purchase_order.py#L14-L15 However, the references of the PO merged to the present one are not merged as well.

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

Forward-Port-Of: odoo/odoo#263016
Forward-Port-Of: odoo/odoo#261578

In Mexico, the basic salary must be calculated based on the total calendar days of the period. This ensures that both worked days and non-working days (e.g. Sundays) contribute equally to the total payment. This calculation also applies to the daily schedule, as the proportional daily wage must be divided equivalently across the hours of the day.

Current behavior:
When an employee has an unpaid leave, the basic salary is incorrectly prorated using only the registered days/hours.
Example: For a monthly wage of 30,000 MXN in a month with 22 scheduled days (21 attendances + 1 unpaid leave), the implicit daily rate becomes 1,363.63 (30,000 / 22). This leads to an incorrect basic salary of 28,636.36 MXN for the days worked. This also happens with unpaid leave for x hours, e.g., for 2 hours, the unpaid leave is calculated as 2 hours * (30,000 / (22 days * 8 hours)) = 340.90 MXN, which is incorrect.

Expected behavior:
The basic salary should be derived from the full period (e.g., 30 days for a month, 15 for a bi-weekly period).
Example: For a 30,000 MXN wage, the daily rate should be 1,000 MXN (30,000 / 30 days). If there is 1 unpaid leave, the basic salary should be 29,000 MXN (29 days * 1,000 MXN), regardless of the number of scheduled working days in the calendar. For unpaid leaves by hours, e.g., for 2 hours, the unpaid leave should be calculated as 2 hours * (30,000 / (30 days * 8 hours)) = 250.00 MXN.

To achieve this, the calculation of out of period days in
`_get_worked_day_lines` was adjusted:
* Create a new function to define how to calculate the out of period days. This avoids overriding the entire _get_worked_day_lines method and ensures that the multi-version logic remains intact.
* The overridden behavior considers the calendar days.

To ensure consistency in total period days, we must adjust/limit the days for irregular periods. For instance, in monthly payslips involving months with 28, 29, or 31 days, the paid days should align with the schedule_pay parameter (e.g., 30 days). This logic also applies to bi-weekly pay schedules.
To achieve this, worked hours are adjusted in `_preprocess_work_hours_data` under the following conditions:
* An associated payslip is required to determine how to limit worked hours.
  For example, when `get_work_hours` is called by the `l10n_mx_regular_pay_holidays_on_time_sub` rule for a specific period, the adjustment is not applied because the period is not linked to a payslip and it follows the standard behavior.
* Adjustments are not applied when calling from a recordset, only a singleton, because each version could contain different configurations (e.g., `schedule_pay`, `employee_id`, `calendar_id`). In such cases, we fall back to the standard behavior.
  This does not mean a payslip cannot have multiple versions. The worked hours calculation is triggered for each version independently; meaning for a payslip with two versions, the preprocess function is executed twice (once per version).

If the preconditions are met, the adjustment is applied to the Attendance entries based on the difference between the `effective_days` and the `work_time` calculated from the `work_data`.

### Case: payslip does not cover the complete pay period
Current behavior:
If a payslip is created for a partial period, the total amount is the full period wage.

Expected behavior:
The total amount should be pro-rated based on the days of the period. For example, if a payslip is created for 25 days(with a monthly schedule pay), the total amount should be the daily salary multiplied by 25 days.

To achieve this, `_compute_amount` is updated to calculate the wage based on the `l10n_mx_daily_salary`.

Changes on tests:
* Add:
  * `test_monthly_payslip_with_partial_leave`, `test_partial_payslip`, `test_partial_payslip_new_hire_month_31_days` and `test_partial_payslip_new_hire_month_28_days`.
  * `test_hourly_payslip_by_attendance` to validate when `Work Entry Source` is set to "attendance".
* Update:
  * `test_hourly_payslip`, `test_monthly_payslip` and `test_partial_payslip_new_hire` to align with the new calculation.
  * Adjust payslips dates to match the `schedule_pay` in `test_regular_payslip_subsidy` and `test_weekly_schedule_pay_no_code`
  * Fix a one-day difference in `TestMxEdiHrPayrollCommon`(16 days instead of 15 days for a bi-weekly schedule), and update the corresponding CFDI values.
* Refactor tests and add new helpers.

### Error on [warning issues generation][1] and [`_compute_is_wrong_duration`][2]

The warning: `"The duration of the payslip is not accurate according to the structure type."` appears with these custom periods for Mexican Payroll, although the period is correct:
* `10_days`
* `14_days`
* `bi-weekly`

Steps to replicate:
* Install `l10n_mx_hr_payroll` module.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Employees and open "Cesar Osbaldo Cruz Solorzano".
* Click on "Payroll" tab, change the "Pay Schedule" to any option listed above, for example "Bi-weekly".
* Go to Payroll > Payslips > Payslips and create a new pay run.
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and the Period '01/01/2026 -> 01/15/2026'.
* Click on "Continue", select Cesar and click on "Select".
* It appears the warning issue.

Problem:
The warning is raised because of `slip.date_from + slip._get_schedule_timedelta() != slip.date_to` condition, because `_get_schedule_timedelta` function calls [`self._schedule_timedelta(schedule, self.date_from)`][3] without the `country_code` argument.
In the Mexican Payroll [_schedule_timedelta is overriden][4] but it is necessary to call it with the country code to use the custom periods; similar to how the [`date_end` is computed][5].

Solution:
Call `_get_schedule_timedelta` passing the `country_code`

[1]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1367
[2]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1454
[3]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L275
[4]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/l10n_mx_hr_payroll/models/hr_payslip.py#L58
[5]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip_run.py#L211

target: 19.0
task-6073601

Forward-Port-Of: odoo/enterprise#114811
Forward-Port-Of: odoo/enterprise#112524

**Steps to reproduce:**
1- Create a new PO/SO/Invoice.
2- Add a new order line and select a product.
3- Click on the UI dropdown to hide the Product column/field.
4- In the Description column (stored as name in the model), the product name appears by default. Delete it and write a manual description.
5- Enable the Product column once again.

**Issue:**
The description no longer appears under the product name in the form view

**Why this happens:**
Commit https://github.com/odoo/odoo/commit/bd5b86e1596e0058ff8f46a79b7c1a918f1d4adc introduces the new logic below:
`this.currentProductName = this.productName ? label.split("\n")[0] : "";`
which assumed the label will always come from the backend in the form [Product Name] + [Product Translation]
So when the following condition was checked, it evaluated to true and the description was truncated:
`else if(this.currentProductName && label.startsWith(this.currentProductName))`

However, a customer can manually edit the description like mentioned above, removing the product name from the description (`name`) column.

Additionally, the fix affected another flow. When you create a product with a Vendor Product Name/Code for vendor X and then create a RFQ for vendor X with that product, the Vendor Product Name/Code no longer appears in the description.

**Resolution:**
Since the fix for the initial problem is causing significant side effects across multiple flows, we decided to revert
the fix.

opw-6189252

Forward-Port-Of: odoo/odoo#263305

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

**Issue:**
In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear. The navbar remains stuck in mobile mode even when there is enough space to display the full layout.

**Fix:**
The navbar was relying on `env.isSmall`, which is only set during initialization and does not react to window resizing. This has been updated to use `this.ui.isSmall`, which is reactive and updates dynamically when the viewport size changes.

**Before:**
After resizing from mobile to a larger width, the navbar continued to behave as if it were still in mobile view, keeping menu items and the app icon hidden.

**After:**
When the screen width increases, the navbar correctly detects the change and re-renders, restoring the menu items and app icon as expected.

opw-6107660

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

Forward-Port-Of: odoo/odoo#263482
Forward-Port-Of: odoo/odoo#263039

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

### Issue:
When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries

### Cause:
`expected_currency_rate` was recomputed when `delivery_date` changed, but the new value was never automatically applied

In addition, after https://github.com/odoo/odoo/pull/225407, `_sync_tax_lines` partially updated the lines:
https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L3029-L3031
https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L1633-L1637
These methods reapply the previous tax rate, causing base and tax lines to be updated inconsistently
As a result, when the base amount increases, the tax amount decreases, and vice versa

### Steps to reproduce:
- Install `l10n_hu_edi` and `accountant` with demo data, then switch to the `HU company`
- Go to Currencies → USD and add two rates:
April 5: HUF per Unit = 100
April 6: HUF per Unit = 150
- Create an Invoice: (Any customer, Currency: USD, Line: Price = 1000, Tax = 27%)
- Open the Journal Items and duplicate the browser tab for comparison
- In the duplicated tab, change the Delivery Date to April 5 and save
- Change the Delivery Date back to today and compare both tabs

### Before the fix:
The values differ between both tabs because the tax lines keeps the old exchange rate

opw-5801126

Forward-Port-Of: odoo/odoo#262915
Forward-Port-Of: odoo/odoo#258310

The current query to delete unnecessary records from `res.device.log` must be run on all records in the table.
This means that the entire table will be placed in the psql buffer. This can degrade performance if autovacuum is very frequent.

This commit introduces a fix so that a seq scan does not have to be performed on the table to carry out the cleanup.

We can use an `USING` if the condition on the joined table (L2) significantly reduces the volume before the join.
This will avoid having the corresponding rows from the first table (L1).

Pseudo query:
```sql
DELETE FROM L1
USING L2
WHERE
    <L2_selective_filter>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

If `<L2_selective_filter>` is very selective, PostgreSQL will use L2 as the "base" table for the join.
PostgreSQL will therefore not place the entire table in the buffer.

With:
```
d: device
c: cron
t: time
```
```
d t1 - insert
d t2 - insert
d t3 - insert

c t4 - cleanup (delete d t1 and d t2)

d t3
d t5 - insert
d t6 - insert

c t7 - cleanup (delete d t3 and d t5)

d t6
d t8 - insert

c t9 - cleanup (delete d t6)

d t8

c t10 - cleanup

d t8
...
```
In the example, cron t9 cannot look at the time window between the moment it runs and the last cron t7. The proof is that the device inserted in t6 must be deleted because a device t8 has been inserted.

It is not possible to cleanup between two crons because older lines can still be deleted by a later cron if a more recent line has been inserted after the previous cron.

So if a device is inserted between the time of the current cron (t0) and the previous cron (t-x), it is necessary to scan the entire table to cleanup the previous devices.
Therefore, it is possible to create a filter so that devices for which there has been no new insertion in the table between the two crons (t0 and t-x) do not need to be checked.

Pseudo query becomes:
```sql
DELETE FROM L1
USING L2
WHERE
    L2.last_activity >= <last_cron_time>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

Task-5951999

Forward-Port-Of: odoo/odoo#249738

**Steps to reproduce:**
1- Create a new PO/SO/Invoice.
2- Add a new order line and select a product.
3- Click on the UI dropdown to hide the Product column/field.
4- In the Description column (stored as name in the model), the product name appears by default. Delete it and write a manual description.
5- Enable the Product column once again.

**Issue:**
The description no longer appears under the product name in the form view

**Why this happens:**
Commit https://github.com/odoo/odoo/commit/bd5b86e1596e0058ff8f46a79b7c1a918f1d4adc introduces the new logic below:
`this.currentProductName = this.productName ? label.split("\n")[0] : "";`
which assumed the label will always come from the backend in the form [Product Name] + [Product Translation]
So when the following condition was checked, it evaluated to true and the description was truncated:
`else if(this.currentProductName && label.startsWith(this.currentProductName))`

However, a customer can manually edit the description like mentioned above, removing the product name from the description (`name`) column.

Additionally, the fix affected another flow. When you create a product with a Vendor Product Name/Code for vendor X and then create a RFQ for vendor X with that product, the Vendor Product Name/Code no longer appears in the description.

**Resolution:**
Since the fix for the initial problem is causing significant side effects across multiple flows, we decided to revert
the fix.

opw-6189252

Forward-Port-Of: odoo/odoo#263305

Issue
-----
Putting a max weight on a package type causes getting a rate with Sendcloud to fail.

Steps to reproduce
-----
- Setup Mondial Relay using Sendcloud
- Set a default package type with max weight 2kg
- Create a product with a 500g weight
- Create a SO with the product
- Add delivery
	- Sendcloud Mondial Relay
	- Get rate

> Impossible to get a rate

Cause
-----
When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order.

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81

However, when making the rate call, we use the value returned by `_split_shipping`

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91

which is equal to the maximum weight of the package. This is blocking in some cases, like if
- the real weight is 750g
- the package max is 2kg
- Sendcloud returns a shipping method for [500g;1kg]

Asking a rate for this method & a 2kg package will fail (rightfully so).

Solution
-----
The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one.

Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight.

-----
Ticket:
opw-5947199

Forward-Port-Of: odoo/enterprise#108315

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Forward-Port-Of: odoo/enterprise#116524
Forward-Port-Of: odoo/enterprise#115581

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Forward-Port-Of: odoo/enterprise#116524
Forward-Port-Of: odoo/enterprise#115581

Issue
-----
If the account on which stock revaluation is registered has a default tax, the account moves generated by changing the price of the product include the tax.

For context, the issue was reported because some l10n modules use accounts with default taxes (eg l10n_de).

Steps to reproduce
-----
- Install a localisation to have default accounts set up
- Create a product category (Cat1)
	- Set Inventory Valuation to "Automated"
	- Set a default tax on the Expense Account
- Create a product Prod1
	- Storable
	- Category set to Cat1
	- Cost set to 500
- Update the on hand quantity of Prod1 to 1
- Change the price of Prod1 to 300
- Go to Accounting > Accounting > Journal > Journal Entries

--> There is an AM for 200 + tax instead of just 200

Discussion
-----
When manually changing the cost of the product, we call

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/product.py#L354

Where we create the AMs

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/stock_valuation_layer.py#L294

This creates the corresponding debit/credit AMLs. Afterwards, we go through

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3210

Which calls `_sync_tax_lines` where AMLs are created for the taxes

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3088

Solution
-----
The AML's `tax_ids` field is precomputed

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L192-L198

and takes the taxes from the account

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L894

By explicitly stating an empty value when we create the AM in `_change_standart_price_accounting_entries`, we avoid the compute so tax lines don't get created.

-----
Ticket:
opw-5929774

Forward-Port-Of: odoo/odoo#256024

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#116593
Forward-Port-Of: odoo/enterprise#115100

Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Forward-Port-Of: odoo/enterprise#116524
Forward-Port-Of: odoo/enterprise#115581

### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

### Steps to reproduce:
- Download 'Manufacturing' app
- Create a product and set its UoM to kg
- Create a BoM for the product with the UoM in grams and the 'Quantity' is 1000+. The components can be in kgs
- Create and produce 2 MOs, one in grams and one in kgs, for the new product
- From the 'Reporting' > 'Production Analysis', choose pivot view
> 'Quantity Produced' is in *millions*

### Cause of Issue:
The issue was produced by PR:https://github.com/odoo/enterprise/pull/50398. https://github.com/odoo/enterprise/blob/5db870f93d8e2f5a4480561c483142eb99f3d0fe/mrp_account_enterprise/reports/mrp_report.py#L269-L270 the calculation above divides quantity produced by `uom.factor` which represents the stock move's UoM relative to the reference UOM (in this case 1 -> 1g = 1 Units). Then, the result is multiplied by `uom_prod.factor` which represents the stock move's UoM relative to the product's UOM (in this case 1000 -> 1000g = 1 kg), which results in the 'Quantity Produced' being in millions.

opw-5955893

Steps to reproduce:
---------------------------------------
1. Install the `sale_timesheet_margin` module
2. Create a product as follows:
    * Type: Service
    * Invoicing Policy: Prepaid/Fixed Price
    * Create on order: Nothing
    * Cost: Add some cost to the product (e.g., 30)
3. Create and Confirm Sale Order with Product (Add Cost field in SOL from the optional field)
4. Now add a new Sales Order Line (SOL) with the same product


Observation:
---------------------------------------
The cost of the recently created Sales Order Line (SOL) is 0.0, which is not correctly calculated based on the product's cost.

Issue:
---------------------------------------
The `_compute_purchase_price` method has a filter (`service_non_timesheet_sols`) that excludes certain sale order lines from the parent's purchase price computation. When a new sale order line is added to an already confirmed sale order (state='sale'), the new line inherits the parent SO's state immediately. That means, the new line matches the filter criteria and gets excluded from parent computation. The `purchase_price` is never calculated from the product's `standard_price`

Solution:
---------------------------------------
The added condition, like  EITHER:
1. Has timesheets recorded (`sol.timesheet_ids` is truthy) → Preserve existing cost
2. OR product has NO standard price (`not sol.product_id.standard_price`) → Use timesheet-based costing

Code intentionally skips the computation of `service_non_timesheet_sols` lines to preserve existing values

opw-5351724

Forward-Port-Of: odoo/odoo#253860

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#110792

Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.

Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.

Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.

Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
  company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.

opw-5462037