__
## Short functional explanation of the error
While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and
hr_work_entry_attendance are both installed.
When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs.

## Reproduction Steps
1. Install hr_work_entry_attendance.
2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset.
3. In Settings, check the Automatic Check-out box.
4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty.
5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually.

### Expected behavior
The attendance check-out should be set at the end of April 17th.

### Unexpected behavior
An error occurs:
`Expected singleton: hr.attendance.overtime.line(39, 40)`

## Origin of the issue
When the attendance goes over several days, we set the check-out date to:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59.
Because of that, at the return:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April.
We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance.
So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs.
__
opw-6036064

### **Steps to Reproduce:**
1) Install sale_renting_planning, hr_holidays with demo data.
2) Create a public holiday for Standard 40 hours/week
3) Create a service product with below configuration:
- check Plan Service as Projector click on internal link and check
   `Sync Shifts and Rental Orders`.
4) Planning>Configuration>Materials for projector 1 and 2 remove working time.
5) create a rental order for this product during public holiday and click on
   confirm.


### **Error:**
```
ValidationError:
This Sales Order can't be confirmed. No resources are available for the shifts in: Test.
```
### **Root Cause:**
while evaluating resource availability during a rental confirmation from [_planning_slot_vals_list_per_sol](https://github.com/odoo/enterprise/blob/a65723cae215495f0d18cb64b3da36ae6f06affd/sale_renting_planning/models/sale_order_line.py#L30-L117), it retrieved all leaves overlapping the rental period.

If any of those leaves were global leaves(`resource_id=False`), then `all_resource_leave` is set to `True` at [1].

This forcefully marked all available resources as unavailable. It failed to check if the global leave actually belonged to the specific `calendar_id` of the available resources. which leads to blocking fully flexible resources or resource with different working calendar.

[1]- https://github.com/odoo/enterprise/blob/a65723cae215495f0d18cb64b3da36ae6f06affd/sale_renting_planning/models/sale_order_line.py#L57-L60

### **Fix:**
- Update the `resource.calendar.leaves` search domain to explicitly filter for global leaves that have no `calendar_id` or that share a `calendar_id` with the available resources.
- Modify the leave processing loop so that calendar-specific global leaves are only applied to resources operating on that exact calendar, rather than indiscriminately blocking all resources.

**opw-6166749**

Steps to reproduce:

**Setup**
1. Install Work Entries (which will install the other necessary modules)
2. Create a new employee with a fully fixed working schedule
3. Make sure their contract date is set (preferably in the past)
4. Ensure that the employee and working schedule are in a timezone that has a positive UTC offset
5. Ensure that "Automatic Check-Out" is enabled in Attendances

**Reproduction**
1. Create an attendance for your employee that falls right before a non-working day 
a. Make sure you do this so it spills over into the next day and will be picked up by the cron. I did this by going to the previous Friday and having the attendance start that morning. 
b. The date has to be after the employee's contract has begun
3. Remove the check-out time so the attendance is still running
4. Go into "Scheduled Actions" and manually run the cron
5. Observe the traceback

In the "Automatic Check-Out" scheduled action for Attendances, we attempt to calculate the correct check-out time for attendances that are over the set hour tolerance. To do this, we temporarily set the check-out time of the attendance to 11:59PM of the date of check-in. When we set this, in timezones with a positive UTC offset, the time will spill over into the next day. This causes two overtime records to be temporarily generated when normally, only one is generated. Ths causes issues when a function in teh Work Entries module is ran, as it checks the status of the overtime lines. Since there are two, we get a singleton error here, as it only expects one overtime line. This fix corrects this by ensuring that the write method is not called on the attendance record, utilizing a temporary variable instead, and preventing the multiple overtimes from ever being generated.

[opw-6198323](https://www.odoo.com/odoo/project/49/tasks/6198323?debug=assets)

**Issue:**
The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'.
This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification.

**Steps to reproduce:**
- Setup a 'sepa_ct' payment method on a bank journal.
- Create a bill with a vendor with a trusted bank account.
- Create a payment for that bill with a 'sepa_ct' payment method.
- Add the payment to a batch.
- Manually set the `payment_online_status` = 'pending'.
- Create a bank transaction and reconcile it with the batch.
- Try to unreconcile the lines on the transaction
- Result: UserError 'You cannot modify a payment that has already been sent to the bank.'

**Fix:**
Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow.

OPW-6080464

**Steps to produce:**
- Install `sale_mrp_renting`.
- Enable `Rental Transfers` from settings.
- Create a rental product.
- Create two variants of the product.
- Create a BoM for one variant and set its type to `Kit`.
- Create a rental order using the other variant.
- Try to confirm the order.

**Issue:**
In versions 17 and 18, a UserError is raised-
```
The unit of measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please correct
the unit of measure defined on the order line or on the product, they should
belong to the same category.
```

From version 18.2 onward, a different error occurs
```
ZeroDivisionError: float division by zero
```

**Root cause:**
In versions 17 and 18:  At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from  `_compute_quantity` method. In version 18.2+:  At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error.

**Solution:**
Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`.

[1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13
[2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20
[3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21
[4]
https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676

**opw-6082434**

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089

Forward-Port-Of: odoo/enterprise#116626