## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/enterprise#103485
Forward-Port-Of: odoo/enterprise#99373

Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source.

**Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):**
 - Install the `hr_work_entry_planning_attendance` module.
 - Go to `Employees` and create a `new employee` or open an `existing one`.
 - In the `Payroll` section, set `Work Entry Source` to `Planning`.
 - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%.
 - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates.

**Error 1:**
`AttributeError: 'method_descriptor' object has no attribute 'min'`

**Error 2:**
`TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given`

**Cause:**
When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot.
If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. 
Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples.

**Fix:**
This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format.

[1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57

[2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60

**No Task ID**

Forward-Port-Of: odoo/enterprise#103662

Steps to reproduce:
-
  1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship).
  2. Create a Sales Order for a product and fully process the delivery, including all steps.
  3. Create a Helpdesk ticket for that customer.
  4. From the ticket, click the "Return" button to open the wizard and select the sales order.

Issue:
-
The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation.

Cause:
-
Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary.

Fix:
-
The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order.

task-4948134

Forward-Port-Of: odoo/enterprise#103883
Forward-Port-Of: odoo/enterprise#93154

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

Forward-Port-Of: odoo/enterprise#103749
Forward-Port-Of: odoo/enterprise#101911