Pre-requisite:
------------------------------
1. Install the Time Off module with the demo
2. Working schedule > Duplicate 'Standard 40 hours/week' schedule
3. Rename it > Add any Date in 'Starting Date' for all days of the schedule
4. Create a new employee with this New Working Schedule
5. Create a new Time off type with 'Take Time Off in' field set to 'Hours'

Steps to reproduce:
------------------------------
1. Time off > Management > Allocations
2. Click 'New' > Change time off type to Newly created time off type
3. Add the Newly Created Employee to Allocation

Observation:
------------------------------
1. Allocation hours are automatically set to 0
2. Even after manually updating the hours, saving the record resets them to 0

Issue:
------------------------------
The computed field `number_of_hours_display` relies on `_get_hours_per_day` method to get the hours per day.  In the `_get_hours_per_day` method, it will return the calendar hours even when they are 0 and return 24h for the employee with no calendar (fully flexible).
This results in allocation hours always being computed as 0

In the previous version, it was not the issue, as we had statically passed 8 hours, If the calendar has no `hours_per_day`
https://github.com/odoo/odoo/blob/97bde303ab3dae81215f8a1c52714d44916d79e1/addons/hr_holidays/models/hr_leave_allocation.py#L236

Solution:
------------------------------
1. For an employee with no working schedule (Fully flexible) returns 24
2. Returned HOURS_PER_DAY (8h) if the calendar has 0 working hours, as allocation with 0 hours makes no sense

opw-6042203

Steps to reproduce:
--------------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company.
3. Create an employee and create a user with HR rights but without Payroll rights.
4. Log in with this new user.
5. Update any value on the employee form (e.g., marital status or add a tag).

Issue:
-----------
Updating the employee raises the following error:
```python
You do not have enough rights to access the fields "slip_ids" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 2
Fields:
- slip_ids (allowed for groups 'Payroll / Officer: Manage all contracts')
```

Cause:
---------
After this 4416eda, open payslips are recomputed automatically on every employee update:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L210-L213
`slip_ids` is restricted to payroll users:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/hr_payroll/models/hr_employee.py#L14 As a result, when an HR user without payroll rights updates an employee,
accessing slip_ids raises an **AccessError**.

Solution:
-----------
Use sudo() when accessing slip_ids so HR users can update employee records 
without issue.

**NOTE:**
The issue has been resolved from version saas~18.4 with the following commits:
279f09a9587674c035c514f966788a4dddfe9794 and  75d66d8

opw-6210358

**Description of the issue/feature this PR addresses:**

When generating a SEPA QR code for a vendor bill payment, the embedded 
amount could occasionally contain excess decimal places instead of 
respecting the currency's expected precision.

This occurs because the `amount` variable in `_get_qr_vals` was being 
converted directly using `str(amount)`. Due to Python's floating-point 
arithmetic, the float value in memory can contain decimal drift.
Directly casting it to a string exposes this drift in the payload.

This commit resolves the issue by replacing `str(amount)` with 
`float_repr(amount, currency.decimal_places)`. This safely bypasses 
the float representation issue, ensuring the string strictly respects 
the currency's configured decimal precision before being injected 
into the QR code.

opw-5504258

**Steps to reproduce:**

- Select company “My Belgian Company”
- Create a 23% purchase tax
- Create vendor bill
   - Select Vendor “BE Company CoA”
   - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73
   - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show

**Current behavior before PR:**

- When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift.

**Desired behavior after PR is merged:**

- The SEPA QR code is generated with the correct number of decimal places.

Forward-Port-Of: odoo/odoo#267293

Description of the issue/feature this PR addresses:
When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `ProcurementException` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user. Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.
 System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs.
Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity. This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.
    Steps to Reproduce on Runbot/Fresh Database on version 18.0:
    1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
    2. Restrict the main Admin (Runbot) user strictly to Company A.
    3. Create a Shared Product (Company field left blank).
    4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
    5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
    6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
    7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
    8. Check the `mail.activity` record for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
    9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.
    
[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)

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