During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g., '84,0'). These string values are later reused in computations, leading to errors like:
```.py
File "/home/odoo/src/enterprise/19.0/l10n_nl_intrastat/models/account_intrastat_report.py", line 163, in l10n_nl_export_to_csv
    supp_unit = str(round(res['supplementary_units'])).zfill(10) if res['supplementary_units'] else '0000000000'
TypeError: type str doesn't define __round__ method
```
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/l10n_nl_intrastat/models/account_intrastat_report.py#L164 This occurs because the export logic expects numeric values, but receives localized strings or None.

Cause:
`formatLang` is applied at the report data level, converting floats into locale-formatted strings. These values are then used directly in arithmetic operations without normalization.

Fix:
Normalize values before computation by:
- Converting input to string
- Replacing locale-specific decimal separators (',' -> '.')
- Casting to float
- Falling back to 0 when value is None or empty

opw-6182286

Forward-Port-Of: odoo/enterprise#116166

*= test_l10n_us_hr_payroll_account

The employer matching cap for pre-retirement plans (401KMATCHING) evaluates to zero for hourly wage employees if wage is set to zero.

### **Steps to Reproduce:**
1) Install l10n_us_hr_payroll.
2) Create an employee with an hourly wage and set the fixed wage to 0. 
3) Configure the retirement plan parameters as follows:
  - 401(k) = 3%
  - Matching Amount = 100%
  - Matching Yearly Cap = 100% 
4) Generate a payslip for this employee and compute the sheet.

### **Observed Behavior:**
The "Benefits Matching to Retirement Plans" line computes as zero for the hourly employee.

### **Expected Behavior:**
The employer matching contribution should dynamically scale based on the actual gross pay period earnings instead of evaluating to zero.

### **Root Cause:**
The calculation of `partial_cap` uses `version.wage` directly at [1]. For hourly employees, the fixed 'wage' field defaults to zero, causing the entire multiplication to cancel out.

[1]- https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L167

### **Fix:**
This commit computes the retirement matching eligibility cap from
`gross annualized wages` and applies the employer matching percentage on
the eligible contribution amount. This ensures retirement matching is
calculated consistently regardless of the employee's contract type.

**opw-6181024**

Forward-Port-Of: odoo/enterprise#120570
Forward-Port-Of: odoo/enterprise#119370

Steps to reproduce:
----------------------------------------
- Create two rules in an overtime ruleset:
    - Non-working hours rule: 
        - Timing
         - Outside of a specific schedule
         - Select a schedule working Monday to Friday
    - Weekend rule:
        - Timing
        - On any non-working day
- Give this ruleset to an employee
- Create an attendance for this employee
    - from 21pm on Friday
    - to 4am on Saturday, the next day
- Check the overtime lines of the attendance
- There is only one overtime line for the first rule

Cause:
----------------------------------------
In the overtime refactor 49952e57ab2e8af908112fa77acd22a5e26fa627 the method `_get_dates()` was introduced to get the dates which an attendance overlap.

It uses `rrule()` to create a list of datetime:
`list(rrule(DAILY, dtstart=localized_start, until=localized_end))`

But `rrule` is returning a new date every 24 hours after the time given in `dtstart`. In our example only the datetime onat 21pm on Friday is returned. If it was ending after 21pm on Friday this time would also be returned.

These dates are given as `min_check_in` and `max_check_out`. So later these dates are used to calculate the non-working days:

https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L441-L448

Only Friday is returned, so the second rule is ignored.

Solution:
----------------------------------------
We use `date()` when calling `rrule()` so the hours are ignored.

This has no impact as `min_check_in` and `max_check_out` are always used later with `datetime.combine(min_check_in, datetime.min.time())`.

opw-6159674

Forward-Port-Of: odoo/odoo#267202

Steps to reproduce
1. Set warehouse to 2-step incoming (Input → Stock)
2. Enable "Propagation of carrier" on the push rule (Input → Stock)
3. On the vendor, set "Purchase Orders Grouping" to "Always"
4. Create a storable product with the Buy route and that vendor
5. Create two sale orders for that product, each with a different delivery carrier
6. Confirm both sale orders → a single merged purchase order is created
7. Confirm the purchase order → a receipt (Vendors → Input) is created
8. Validate the receipt → ValueError: Expected singleton: delivery.carrier(1, 3)

Issue
In `_get_new_picking_values`, when the push rule fires to create the internal transfer (Input → Stock), the carrier is fetched from the referenced sale orders: carrier_id = self.reference_ids.sale_ids.carrier_id.id https://github.com/odoo/odoo/blob/5fb0c1f1460949043aa23ddbed09bdbfdc4a8482/addons/stock_delivery/models/stock_move.py#L45

Because both sale orders share the same merged receipt, the receipt move references both. When those SOs have different carriers, `self.reference_ids.sale_ids.carrier_id` returns a multi-record recordset and calling `.id` raises `ValueError: Expected singleton: delivery.carrier(1, 3)`.

opw-6126760

Forward-Port-Of: odoo/odoo#270168
Forward-Port-Of: odoo/odoo#262671

*=l10n_ch_hr_payroll,hr_payroll_account_iso20022

When clicking the create payment report button on a payslip for a Swiss company,
a traceback occurs if the ``hr_payroll_account_iso20022`` module is not installed.

Steps to reproduce the error:
- Install ``l10n_ch_hr_payroll`` module
- Switch to CH Company
- Create an Employee and running contract for it
- Go to Payroll > Payslip > All payslips > Create a new payslip > Set the employee > Confirm > Create payment report

Traceback:
```py
ValueError: Wrong value for hr.payroll.payment.report.wizard.export_format: 'iso20022_ch'
```

https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip.py#L383 https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip_run.py#L13
Here, ``iso20022_ch`` is passed as ``export_format``,
However, ``iso20022_ch`` is added to the selection field in the ``hr_payroll_account_iso20022`` module at [1].
When that module is not installed, the selection value does not exist, leading to the above error.

[1]: https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L11

sentry-7391832811

Forward-Port-Of: odoo/enterprise#120699
Forward-Port-Of: odoo/enterprise#113277

Steps to reproduce:
--------------------------------------------
1. Install `website_project` module
2. Create a new project
3. Add a customer to the project
4. Go to customer > add email and phone
5. Create a new task in that project:
    * Observe that the customer is the same as the project
6. Go to Website > Contact Us > Edit > Click on submit button
7. Set action to 'Create a Task' and select the created project in 'Project'
8. Click on Save and Open the URL in Incognito Mode
9. Go to the Contact Us page > Fill in the details > Submit
10. Comeback to our window and open tasks of the created project

Observation:
--------------------------------------------
1. A new task is created using the customer details entered in the form.
2. The existing task’s customer and the project’s customer are also incorrectly updated to this new customer.

Issue:
--------------------------------------------
The bug is in the `extract_data` method of the website form controller for projects.
A non-logged-in user submits the Contact Us form with name and an email that doesn't match any existing partner. The old code's `else` branch would set `partner_name` in the task record values without setting a `partner_id` https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/controllers/main.py#L65-L66

During task creation, the computed field `_compute_partner_id` automatically sets `partner_id` to the project's partner
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/project/models/project_task.py#L1440-L1441

`partner_name` is defined as
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/models/project_task.py#L12

In Odoo, a related field is essentially a shortcut to a field on a linked record The key attribute here is `readonly=False`. This tells Odoo:
    * On read: Get the value from `self.partner_id.name`
    * On write: Propagate the write back to `self.partner_id.name` (this is the inverse). So writing `task.partner_name = 'TEST'` is equivalent to writing `task.partner_id.name = 'TEST'`. It modifies the partner record itself, not just the task.

So, the partner record itself was renamed. Every record that references a partner now sees the new name

Solution:
--------------------------------------------
The fix passes `False` to `partner_id`, this way:
    * The existing partner is untouched
    * All other tasks and the sales order keep their correct customer

opw-6206080

Forward-Port-Of: odoo/odoo#270157
Forward-Port-Of: odoo/odoo#264738

Behavior before:
Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts.

Behavior after:
Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation.

Root Cause:
When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing.

Fix:
Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries.

Steps to Reproduce:
1. Have a product tracked by Lot and Package.
2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line.
3. Go to Inventory → Physical Inventory.
4. Set the counted quantity of any reserved bag to 0.
5. Click Apply.
6. Observe that the system takes time to process this single change.
7. Unreserve the delivery order.
8. Perform the same steps as mentioned above.
9. Inventory adjustment is much faster.

opw-6234885

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

Forward-Port-Of: odoo/odoo#270228

**Steps to reproduce:**
- Install the `l10n_de` module and switch to a `DE Company`.
- Enable `Peppol` in the Invoicing app settings.
- Open the `DE Company` customer record.
- In the `Invoicing` tab, change the Peppol ID code from `Germany VAT` 
  to `Germany Leitweg-ID` and set a code (e.g., `13075957-K000-52`).
- In the `Contacts & Addresses` tab, create an invoice-type contact named `test`.
- Create a new invoice using the `test` contact.
- Send the invoice via Peppol.
- Download the generated `XML` and inspect the `BuyerReference` field.

**Observation:**
The `<cbc:BuyerReference>` field is set to `N/A` instead of the configured `Leitweg-ID`.

**Root Cause:**
At [1], the `BuyerReference` node is populated using `vals['customer']`. 
For invoices addressed to an invoice-type contact, the contact itself 
does not contain the Peppol configuration, which is stored on the 
commercial partner. As a result, the code fails to retrieve the 
customer's `Leitweg-ID` and leaves the `BuyerReference` field empty.

**Fix:**
This commit ensures that the configured Leitweg-ID is correctly added to the 
`BuyerReference` field for child contact.

[1]:
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_xrechnung.py#L87-L97

opw-6269478

Forward-Port-Of: odoo/odoo#270459
Forward-Port-Of: odoo/odoo#269818