Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it.

## Observed Behavior:
Failed to read field mrp.workorder.employee_analytic_account_line_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised.

During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error.

**Why does this error not occur in 19.3+?**
Commit [3] added `sudo` to allow cancellation of workorder
[2]:
https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26
 
## Solution:
Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3].

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

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

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

*=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#120433
Forward-Port-Of: odoo/enterprise#113277

Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it.

## Observed Behavior:
Failed to read field mrp.workorder.employee_analytic_account_line_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised.

During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error.

**Why does this error not occur in 19.3+?**
Commit [3] added `sudo` to allow cancellation of workorder
[2]:
https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26
 
## Solution:
Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3].

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

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

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

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Put your warehouse in delivery in 2 steps
- On the receipt operation type change the return operation type to be "pick" by default.
- Create and confirm a PO for 1 unit of P
- Validate the receipt > return > Create the return for 1 unit
- Change the operation type of the return from Pick to Delivery to return the product in one step.
- Validate the return
#### > The qty_received is updated from 1 to 2 instead of 0.

### Cause of the issue:

Updating the `picking_type_id` of the return will also update the `location_dest_id` to the default values:
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/stock/models/stock_picking.py#L1138-L1147
However, the default values of the `Delivery` is "Partner/customer". As such, the location dest of the move is also updated to be "Partner/customer". Now the issue is that the `qty_received` only considers moves to be returned if the location dest usage is not 'supplier':
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase/models/purchase_order_line.py#L226-L231 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L55-L67 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L76-L77 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/stock_move.py#L129-L131

opw-6292918

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

Forward-Port-Of: odoo/odoo#269867

*: l10n_{ar,co,in,pe,uy}_pos

**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.

Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.

**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).

Add a test to prevent future regression.


**Note:**
Another possibility is to re-inherit for each localization the new
standalone view, but this fix would need to update the module to work,
while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really
want to go back to each localization needing to inherit backend views.

[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0bd77659b87359f2ca8763702462aaf92R26

opw-6244777 (many more)

*: br,cl,ec,gt,it,ke,mx

**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.

Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.

**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).

Add a test to prevent future regression.

**Note:**
Another possibility is to re-inherit for each localization the new standalone view, but this fix would need to update the module to work, while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really want to go back to each localization needing to inherit backend views.

[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0>

opw-6244777 (many more)

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120793
Forward-Port-Of: odoo/enterprise#120051

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

Steps to reproduce
---
1. Set an employee to work 8 hours per day.
2. Open the timesheet timer in the systray, type a duration like 8:00 and save.
3. Open the My Timesheets grid for that day.

The day is marked as overtime (yellow) even though only 8 hours were logged.

Issue
---
While the entry is open the timer keeps running and, every second, writes the elapsed time into unit_amount down to the second. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L89-L102

When the duration is set by hand, the save skips the usual rounding and keeps the value as it is. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L120-L132

So the clean 8:00 the user typed gets a few extra seconds from the next timer tick (8h 1s, stored as 8.000277) and is saved with them. The seconds are hidden in the HH:MM display but are enough to push the day above its working hours, so the grid paints it as overtime. This timer form is new in saas-19.2 (c3dac6ccdb5), which is why earlier versions are not affected.

The fix ignores timer ticks once the duration has been set by hand, so the typed value is kept.

opw-6180676
---

Currently, an error occurs when opening the gantt view of work orders.

**Steps to Reproduce:**
 - Install `mrp_workorder` with demo data.
 - Go to `Settings` > `Technical` > `Resource` > `Resources`.
 - Open the `Assembly 1` resource and remove its `working time`.
 - Go to `Manufacturing` > `Operations` > `Work Orders`.
 - Switch to the `Gantt view`.

`KeyError: 22`

when the user opens the Gantt view, the system checks the unavailability of work centers and employees 
based on their resource calendars. While computing unavailable intervals for resources [1], resources 
without a calendar are flexible resources. If no leave interval exists within the specified start and end 
range that matches the domain, the resource is not included in the result [2]. when updating the 
unavailable intervals dictionary [3], the resource is missing. As a result, when it later tries to access 
the unavailable intervals for that resource, it raises an error [4].

This commit prevents the error by safely handling resources that are not present in the unavailable 
intervals dictionary by using an empty list instead.

[1]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L186

[2]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_calendar.py#L532-L536

[3]:https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L187

[4] https://github.com/odoo/enterprise/blob/47f2e9e88fa0bbb8852fe7734c6bece4dca8b9d0/mrp_workorder/models/mrp_workorder.py#L692-L694

sentry-7525704808

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024

Forward-Port-Of: odoo/enterprise#120365
Forward-Port-Of: odoo/enterprise#118714

The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities.  `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price.

**Video of the bug:**
https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view

**Issue:**
When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed.

**Reproduction steps:**
- Have a main company
- Create a branch company
- Create a product, configure it as FIFO on both the main company and branch company 
- Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes)
- On the main company, set the product cost to $15 (for demonstrative purposes)
- Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt
- Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect)

**Fix:** 
Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company

Related ticket: opw-6064126

Forward-Port-Of: odoo/odoo#269942
Forward-Port-Of: odoo/odoo#258199

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

Currently, when a user without accounting permissions attempts to duplicate a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO and try to duplicate it.

## Observed Behavior:
An Access Error is displayed saying failed to read mrp.production.wip_move_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised during record duplication.

During duplication, `copy_data` is called, and the error occurs when invoking the super method at [2], because the user does not have read access to the `wip_move_ids` field on account.move.

**Why does this error not occur in 19.3+?**
Commit [3] prevents the `wip_move_ids` field from being copied, which avoids triggering the access check and therefore prevents this error.

[2]-
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1135-L1137 

## Solution:
Prevent copying the `wip_move_ids` fields because, as noted in commit [3], it does not make sense to carry over work-in-progress journal entries from a previous Manufacturing Order to a newly duplicated one.

WIP entries represent accounting values for partially completed goods tied to the original Manufacturing Order, so duplicating those links is both functionally incorrect and can trigger the access error described above.

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/odoo/pull/251731/changes/27b5d5551cc772f238695768478a448da75cac61

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

opw-6204049

Forward-Port-Of: odoo/odoo#264925

Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it.

## Observed Behavior:
Failed to read field mrp.workorder.employee_analytic_account_line_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised.

During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error.

**Why does this error not occur in 19.3+?**
Commit [3] added `sudo` to allow cancellation of workorder
[2]:
https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26
 
## Solution:
Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3].

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

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:

- In the settings enable: Multi-Steps Routes
- Put your warehouse in delivery in 2 steps
- On the receipt operation type change the return operation type to be "pick" by default.
- Create and confirm a PO for 1 unit of P
- Validate the receipt > return > Create the return for 1 unit
- Change the operation type of the return from Pick to Delivery to return the product in one step.
- Validate the return
#### > The qty_received is updated from 1 to 2 instead of 0.

### Cause of the issue:

Updating the `picking_type_id` of the return will also update the `location_dest_id` to the default values:
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/stock/models/stock_picking.py#L1138-L1147
However, the default values of the `Delivery` is "Partner/customer". As such, the location dest of the move is also updated to be "Partner/customer". Now the issue is that the `qty_received` only considers moves to be returned if the location dest usage is not 'supplier':
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase/models/purchase_order_line.py#L226-L231 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L55-L67 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L76-L77 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/stock_move.py#L129-L131

opw-6292918

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

Forward-Port-Of: odoo/odoo#269867

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

Forward-Port-Of: odoo/odoo#267279
Forward-Port-Of: odoo/odoo#263058

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120640
Forward-Port-Of: odoo/enterprise#120051

*: hr_holidays,test_discuss_full

**Steps to reproduce,**
Create an employee linked to a user
Archive the employee and remove the link to the user
Create another employee for the same user
Go to Discuss > 'General' channel
Open the member list and click on the user's avatar

**Before this commit,**
Clicking on the avatar opened a popover showing outdated information from the
archived employee record instead of the new one.

**Cause,**
By default, the server sends employee data ordered by name. Since both records
have the same name, the order is non-deterministic. The client then attempts to
match the employee's company to the current user's company, falling back to the
first record in the list if no match is found.

**Fix,**
Filter out archived records first (treating them as non-existent). Then, sort
the remaining employee records to prioritize those that match the current user's
active company. In case records share the same company, prioritize employees
with a related user. Fall back to descending order of creation for identical
results.

**After this commit,**
Clicking on the avatar shows the correct employee details in the popover.

task-6175765

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

Forward-Port-Of: odoo/odoo#252170

## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#116430

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

FW Changes
-----
Discovered an error by re-enabling the tests, `res.partner` doesn't have a `company_name` anymore, it has been replaced by `parent_name` in [18a59cf](https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483f6ddab87da0c55).

Issue
-----
There are 2 issues with USPS rest:

1. USPS packagings do not have their size UOM displayed. This leads to confusion as users input in inches but the dimensions are treated as feet.

2. USPS returns the same rate regardless of the package type.

Steps to reproduce
-----
- Set USPS up
	- Open the Package Type form > go to its' Dimensions tab

> Issue 1

- Set USPS up (domestic)
	- Select a `Domestic Rating Indicator` (eg LF - Flat Rate Box)
- Create a SO with some product
- Open the delivery widget and add a rate with USPS
	- Discard the changes
- Go to the delivery method and change the rating (eg SP - Single Piece)
- Go back to the SO
- Open the delivery widget and add a rate with USPS

> Issue 2, rate is the same as before

Issue 1
-----
By default, there is no displayed UOM on the form because of

https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/stock_delivery/models/stock_package_type.py#L20-L33

We can change this behaviour for USPS specifically as done in Envia

https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_envia/models/stock_package_type.py#L37-L46

Issue 2
-----
In `usps_rest_rate_shipment`, we request rates for every package of the delivery, which we receive as lists. We then iterate over the list to find the rate matching the `mail_class`. The problem is that this only filters over whether the delivery is domestic or international. We don't filter based on the actual service selected on the carrier (`usps_domestic_rating_indicator` for domestic and `usps_international_rating_indicator` for international).

https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_usps_rest/models/delivery_usps.py#L224-L236

-----
Ticket:
opw-6224918

Forward-Port-Of: odoo/enterprise#120594

Steps to reproduce
------------------
1. Open a PoS session, e.g. at 1h45
2. Wait a bit and make an order, e.g. at 1h55
3. Keep the session open and go to PoS > Reporting > Sale Details.
4. Select a starting date before the ordre and after the session open, e.g. at 1h50
5. Generate the report.

The header shows the starting date of the session, i.e. at 1h45, instead of that of the selected date, i.e. 1h50

Why it's happening
------------------
Commit 5003774bf2a7 changed the way the report decides if the data comes from a single session: now if all the orders in the user selected start and end date belong to one particular session, the start and end date on the report are overriden to be those of that particular session, ignoring the user selected ranges.

The fix
-------
Only overwrite the start and end dates when `session_ids` was passed (i.e. the report is about a specific session).

When called via date range + `config_ids` (from the backend wizard like in our reproduction steps), keep the user-selected range.

opw-6185106

Forward-Port-Of: odoo/odoo#267200

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120640
Forward-Port-Of: odoo/enterprise#120051

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

## The Problem
When grouping messages, the code was accumulating recordsets using the `|=` union operator inside a loop. Since each union call internally builds an `OrderedSet` over all previously accumulated IDs, the performance degraded quadratically relative to the number of document records. This caused bottlenecks on databases with large message volumes.

## The Solution
* Replaced the `|=` recordset accumulation with a plain Python dictionary of ordered sets to store IDs per operation, while keeping same behavior.
* Deferred the `browse()` call until after the loop is complete.
* Reduced the overall complexity from **$O(N^2)$** to **$O(N)$**.

---

## Benchmarks
*Tested on a customer database grouping by "Created By" and "Created On":*

| Record Count | Before | After | Improvement |
| :--- | :--- | :--- | :--- |
| **300k records** | 83.00s | **1.00s** | **-99%** |
| **30k records** | 0.60s | 0.25s | (Minor) |

**Note:** The performance gains become exponentially more significant as the record count grows.

**OPW-6123758**

Forward-Port-Of: odoo/odoo#269123
Forward-Port-Of: odoo/odoo#260147

## Steps to reproduce

- Create an attribute A, of type always, with 2 values, one should have an extra price
- Create an attribute B, of type never, with 2 values
- Create a product that has both those attributes
- Create a combo with that product with both values for A
- Go to the PoS and order that combo with the value that has an extra price for A
- The extra price is added

## Why the fix:

For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo.

As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page.

It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always".

The variants are then considered as different products, as they should in this case.

If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it.

We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 

We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same.

opw-6262431

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

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Forward-Port-Of: odoo/odoo#270343
Forward-Port-Of: odoo/odoo#256932

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#120747
Forward-Port-Of: odoo/enterprise#112654

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#112654

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:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120640
Forward-Port-Of: odoo/enterprise#120051

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Step to reproduce:
- install `l10n_be_pos_blackbox` with demo data
- go to pos → configurations → point of sales
- select 2 or more configs and try to archive

Observation:
- Traceback 
```
  File "/19.0/l10n_be_pos_blackbox/models/pos_config.py", line 73, in write
    if (vals.get('l10n_be_blackbox_be_id') or self.l10n_be_pos_id):
                                              ^^^^^^^^^^^^^^^^^^^
  File "/19.0/odoo/orm/fields.py", line 1659, in __get__
    record.ensure_one()
  File "/19.0/odoo/orm/models.py", line 5940, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: pos.config(3, 4, 5)
```
Cause:
- it looks like `l10n_be_pos_id` is a m2o field and `self.l10n_be_pos_id` should 
work for multiple records, but `l10n_be_pos_id` is a char fields and hence 
this is not resolved and we get error

https://github.com/odoo/enterprise/blob/42e438b1366f48addbe826f363952d3261467c33/l10n_be_pos_blackbox/models/pos_config.py#L20-L26

Fix:
- use `mapped` to check values in multiple records

opw-6305769

The website appointment calendar fills availabilities one month at a time and the update_available_slots route maps the calendar month index to an absolute month from datetime.now(). This only matches the displayed months when the first one is the current month. When the first bookable slot is later, a punctual appointment starting in a future month or any appointment whose "at least X hours before start time" lead time pushes the first slot past the current month, navigating forward requests the wrong month and the reached month renders empty.

In update_available_slots, take the lead time into account when computing the reference month so it lands on the first displayed month: the start datetime for a punctual appointment starting in the future, otherwise now plus the minimum schedule hours. The navigated month index is then added to that reference. This extends https://github.com/odoo/enterprise/commit/f0e5b14a823cf97218f4094d287a328e2744fd73 which only handled the future start datetime.

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type, set Schedule to Weekly and Allow Bookings to On specific dates with a range ending a few months out
3. Set the "at least N hours before start time" field to 360
4. Save and click the Preview button in the header
5. Pick a resource or staff member to reach the calendar
6. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910