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

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

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

Forward-Port-Of: odoo/odoo#257836

**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date. 
```
id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 1_draft            |                   | 2026-05-02
```

- confirm the SO
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         | 2026-05-01        | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         |                   | 2026-05-02
```

- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
 line 175, in _compute_amount_to_invoice
    and (not order.end_date or order.next_invoice_date < order.end_date)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```

- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).

upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)

Forward-Port-Of: odoo/enterprise#115976

# Setup
For easiness of testing : have no purchase order in your dashboard

# How to reproduce
- Create a Purchase Order for Vendor X and with Product Y
- Click on Confirm Order -> Receive -> Validate
- Go back to the dashboard

# The problem
The displayed OTD is 0%, but when you go to the Vendor X form view and check his On-time Rate, it is 100%

# Cause
The computation for the On-time rate in the dashboard uses the whole datetime value, so if there is even a second of difference between `effective_date` and `date_planned`, the PO is not counted as on-time :
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/purchase_order.py#L253

That is not the case for the partner On-time rate computation, where we round the datetime value to the date value : https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/res_partner.py#L57

opw-6128510

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

Forward-Port-Of: odoo/odoo#263341
Forward-Port-Of: odoo/odoo#260384

## Description of the issue this commit addresses: 
When a user attempted to install `sale_project` on an empty runbot instance, the entire runbot would crash.

## Root Cause:
The global variable storing the available `billable_type` selections in `sale_project` (`BILLABLE_TYPES`) was being modified by `sale_timesheet`. Since runbot workers are shared across multiple databases, these modified selection values leaked from one database to another. When these values appeared in databases that did not have `sale_timesheet` installed, the installation of `sale_project` would fail.

## Desired behavior after this commit:
The global variable storing `billable_type` is no longer imported or modified within `sale_timesheet`. Instead, the `selection_add` attribute is used to extend `billable_type` safely and without cross‑database side effects.

task[-6178239](https://www.odoo.com/odoo/project/4105/tasks/6178239)


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