Currently, an error occurs when user makes payment through express checkout on the website.

Steps to Reproduce:
 - Install the `website_sale_loyalty` module.
 - Install `Demo` payment provider.
 - Go to `website` > `Shop` > `Add a product to the cart`.
 - `View cart` > `Pay with Demo` > `Pay`.
 - Click the `back button` (Chrome navbar)
 - Now, click `Pay with Demo` > `Pay` again.

`ValueError: Expected singleton: sale.order()`

The error occurs after this commit https://github.com/odoo/odoo/commit/bf8d08cd22b5d982a6a71353db5979f6b7545bd8,
which overrides method [1] to include the delivery discount, if any.
If order_sudo is empty, it raises this error [2].

This commit ensures that if order_sudo is not present, a UserError
is raised with an appropriate message.

[1]- https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/website_sale/controllers/delivery.py#L160

[2]- https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/website_sale_loyalty/controllers/delivery.py#L18

sentry-6759936549


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

Flexible calendar intervals are computed with date-only boundaries, which can shift the range used for worked time calculations.

### **Steps to reproduce:**
1) Install hr_payroll
2) Create a flexible working schedule with 56 hr per week and 8hrs avg per day 
3) Create an employee with this working schedule and joined from `16th Feb 2026`. 
4) Create a payslip for this employee for the February period.

### **Observed Behavior:**
"out of contract"  working hours are 120:59hr
<img width="1213" height="406" alt="image" src="https://github.com/user-attachments/assets/3f7104fb-3a59-48e3-aaf6-052dcf18c0c0" />

### **Expected Behavior:**
"out of contract"  working hours should be 120hr
<img width="1225" height="429" alt="image" src="https://github.com/user-attachments/assets/98898b16-4e36-4a30-9460-633f32c53ec3" />


### **Root Cause:**
The flexible calendar interval computation trims the interval boundaries by converting them to dates at [1], and assumes `end_datetime` is always midnight at [2]. This ignores timezone effects, depending on the user timezone, `end_datetime_adjusted`, may still fall on the same day, so an extra day can be included in the computation. This produces incorrect worked-hours totals for flexible calendars.

[1]- https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/resource/models/resource_calendar.py#L387-L389

[2]- https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402

### **Fix:**
Keep the full datetime values when computing flexible calendar intervals.

Related Enterprise PR https://github.com/odoo/enterprise/pull/113119

**opw-6017569**

Currently, an error occurs when closing a tab with a new (unsaved) record.

**Steps to replicate Error- 1:**
- Install `hr`.
- Open Employees and click new.
- Give a name and close the tab (without saving).

**Error:**
`KeyError: 'name'`

----

**Steps to replicate Error- 2:**
- Install the `Time Off` module.
- Go to `Time Off > Management > Time Off`.
- Click on New and select an employee and close the tab.

**Error:**
`KeyError: None`

---

**Cause:**
- When closing the tab, the browser triggers both `visibilitychange` [1] and `beforeunload` [2].
- Both attempted to save, resulting in duplicate create calls — one with a valid payload and the other empty which leads to error at line [3].

**Solution:**
- Skip the `beforeunload` urgent save if the record has no `resId`. This ensures that only existing records are saved at tab close.
- Because `beforeunload` is called after `visibilitychange` so we let `visibililitychange` handle the save for new records.

[1]: https://github.com/odoo/odoo/blob/6e6f2a0bc8b6b1dc3ef5f203530c6fb82a67132a/addons/web/static/src/views/form/form_controller.js#L467-L471

[2]: https://github.com/odoo/odoo/blob/6e6f2a0bc8b6b1dc3ef5f203530c6fb82a67132a/addons/web/static/src/views/form/form_controller.js#L482-L488

[3]: https://github.com/odoo/odoo/blob/6e6f2a0bc8b6b1dc3ef5f203530c6fb82a67132a/addons/hr/models/hr_employee.py#L476

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

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690