**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

Currently when the user produces a product, the system shows warnings for components that don't apply to that variant.

## Steps to replicate:
- Install Manufacturing
- Enable Variants from settings
- Create a Product 'Car' with color attribute value: Red and Blue
- Create Bill of material for car:
   - Components: Engine, Radiator
- For the 'Engine' component set color: Blue on 'Apply on Variants' field on
  bom lines (unhide the field as it is hidden by default).
- Create and confirm an MO for Red Car
- Produce All

## Observed Behavior:
A consumption warning is being triggered indicating that the radiator has not been consumed, even though this component is intended only for the blue car variant and not the red car.

## Root cause:
When the Produce All button is pressed, it calls the `button_mark_done` function, which in turn invokes `pre_button_mark_done` as shown in [1]. This eventually leads to the execution of `_get_consumption_issues` as shown at [2].

The issue arises in the loop at [3], where BoM lines are checked for missing components. The filtering logic used to populate the `all_lines` variable incorrectly includes BoM lines that belong to other variants. Specifically, it does not take into account the "Apply on Variants" field, causing lines meant for different variants to be considered.

As a result, these irrelevant lines are treated as missing components and are added to the `missing_lines`, which is then included in the issues list at [4].

**Why this did not occur in versions prior to 19.2?:**
This behavior was introduced unintentionally after [commit](
https://github.com/odoo/odoo/commit/7a406f26c3c846b347498a3cb60b4ac12df53c6e), which revamped the warning wizard to support showing warning without a BoM.

Previously, the expected component values were derived solely from `_get_moves_raw_values`. However, after the change, the logic also considers BoM lines directly. This change led to the inclusion of variant-specific lines without properly filtering them based on the `"Apply on Variants"` field, resulting in the observed issue.
[1]:
https://github.com/odoo/odoo/blob/4f04f26886393843cfdcec97ed1248a8cf0d1957/addons/mrp/models/mrp_production.py#L2214-L2227 [2]:
https://github.com/odoo/odoo/blob/4f04f26886393843cfdcec97ed1248a8cf0d1957/addons/mrp/models/mrp_production.py#L2348-L2366 [3]:
https://github.com/odoo/odoo/blob/5b907e1235e37b2e6f90ac3289d1947f1abd57df/addons/mrp/models/mrp_production.py#L1763-L1781 [4]:
https://github.com/odoo/odoo/blob/5b907e1235e37b2e6f90ac3289d1947f1abd57df/addons/mrp/models/mrp_production.py#L1811-L1813 

## Solution:
To prevent confusion, users should not see warnings for component lines that are not applicable to the current product variant.

This can be achieved by refining the filtering logic to exclude irrelevant BoM lines, using the `_skip_bom_line` which ensures that only BoM lines valid for the current product variant are considered.

By tightening this condition, variant-specific components that do not apply to the selected variant will be ignored, thereby avoiding incorrect consumption warnings.


opw-6086167

__
## Short functional explanation of the error
When an employee has multiple overtimes for the same day, including one that doesn't have a check-out date. When running the scheduled action `Attendance: Automatically check-out employees`, an error occurs: `odoo.exceptions.ValidationError: Duration must be positive and cannot exceed 24 hours.`

## Reproduction Steps
1. Create an employee. Set their timezone to UTC and the Overtime Ruleset to Default Ruleset in the settings tab.
In the Payroll tab, set a contract start date.
2. Set their Working Hours to a fixed 40 hours/week. Set the timezone of the Working Schedule to UTC.
3. Go to attendances and create 2 attendances on a Sunday: one from 06:00 to 06:01 and a second that starts at 06:02 but that doesn't have a checkout date.
4. Go to Settings and enable Automatic Checkout. Leave the Tolerance to 2 hours.
5. Enable debug mode and go to Scheduled Actions. Look for `Attendance: Automatically check-out employees` and run it manually.

### Expected behavior
As the tolerance is 2 hours, the second attendance check-out time should be set at 08:01.

### Unexpected behavior
An error occurs:
`odoo.exceptions.ValidationError: Duration must be positive and cannot exceed 24 hours.`

## Origin of the issue
We retrieve overtime intervals with the domain:
https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_version.py#L34-L42 This will make us retrieve all the overtimes for a given day, even if overtimes belong to different attendances.

However, this means that we will retrieve several times the same overtimes, as this piece of code is executed in this context:

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L35 https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L43

This results in the generation of intervals containing multiple times the same overtimes. We then sum their duration to later create work entries:
https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L47 As we try to create a work entry with too much overtime, that exceeds 24 hours, it raises a validation error.
Moreover, as the overtime hours are always stored in UTC, it makes sense to always keep the timezone as UTC when performing a `_read_group` .
__
opw-6036064

Forward-Port-Of: odoo/enterprise#116194

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#116415
Forward-Port-Of: odoo/enterprise#108315

**Problem:**
On a Belgian company with the UI set to French (or any non English language), the gross line never appears in the salary configurator sidebar when opening an offer.

**Steps to reproduce:**
1. Create a Belgian company.
2. Install French and set the admin user to French.
3. Go to an applicant (e.g Laurie Poiret), create a salary offer, save.
4. Open the offer link (salary configurator).

**Cause:**
The base `_get_compute_results` uses the translated `category_id.name` ("Salaire mensuel" in french) as the dictionary key when writing entries into `resume_lines_mapped`. The payroll override function `_get_period_name`, which for monthly schedules returned the hard coded english string `"Monthly Salary"` instead of the translated category name. This caused a key mismatch: the gross line was stored under the translated key, while the override rebuilt `resume_categories` with the english key so when the template iterates over categories and looks up `lines[category]`, the whole "Monthly Salary" bucket was invisible in every non english language.

**Solution:**
We should now return the `category_id.name` directly (the translated name coming from the record itself). This keeps all keys consistent between `resume_categories` and `resume_lines_mapped` regardless of the language used.

also because in https://github.com/odoo/enterprise/blob/1845042ff388593c4cdf547d47c018f42bd02c7c/l10n_be_hr_contract_salary/controllers/main.py#L450
We use `resume = result['resume_lines_mapped']['Monthly Salary']`
We need to re-design this by using the actual translated names, and building `result` keys based on the language selected (the same should be applied for "Yearly benefits").

opw-6009711

---

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

Forward-Port-Of: odoo/enterprise#116657
Forward-Port-Of: odoo/enterprise#110676