To reproduce:
=============
- Create a 24-hour calendar representing a company without breaks.
- Create an employee who will be working a night shift 21:30 to 6:00
- Create an open shift from 21:30 to 6:00.
- as the company doesn't have breaks the shift will have 8 hours and 30 minutes of allocated hours. Set the allocated hours to 8 hours
- click auto-plan -> the employee is assigned to the shift but the allocated hours are changed
    to 7 hours and 32 minutes.

Problem:
========
- when setting the allocated hours to 8 hours, the allocated percentage changed to 94%.
- after auto-planning, and setting the resource to the shift, the allocated hours are recomputed based on the allocated percentage and the working hours of the resource which is 8 * 0.94 = 7.52 hours.

Solution:
=========
after finding the resource to assign to the shift, we should recomputed the allocated percentage based on the working calendar of the resource and the allocated hours set on the shift.

opw-3874283

Forward-Port-Of: odoo/enterprise#62264

Before this commit, it was impossible to force the use of 'vanilla' ISO 20022 over SEPA in every case. The 'Generic' selection value existed in the PAIN version field, but its actual meaning was to use the regular SEPA, not what the inner code of the module calls "generic SEPA", which actually corresponds to ISO 20022 without the SEPA-specific restrictions.

ISO 20022 is currently automatically used a a fallback by our SEPA implementation when trying to generate a file which values would violate the SEPA restrictions (such as a non-IBAN account or non-EUR amount). This works fine when your wish is to do SEPA and you need something more generic "by accident", and maybe your bank accepts it.

In that context, we got a report from a customer with his journal configured to "Generic", who actually wished to use ISO 20022 instead of SEPA:
- When making a batch payment containing a non-EUR amount or non-IBAN account, this worked fine
- When making a batch payment violating none of the SEPA restrictions, SEPA was used instead of ISO 20022

When SEPA was chosen, SvcLvl node was set to "SEPA" in the file, as it is the only accepted value. This got rejected by the customer's bank, which expected only ISO 20022, in which "SEPA" is not a legit SvcLvl value. With our commit, this node will now receive "NURG" as its value.

This commit is intended as a small patch to unlock customers facing this exact issue. More proper and sandboxed support for ISO 20022 will follow in master.

opw-3848174

Forward-Port-Of: odoo/enterprise#62240
Forward-Port-Of: odoo/enterprise#62054

This traceback occurs when the user makes the `end date` as empty while 
creating a new planning slot with template.

To reproduce this issue:

1) Install planning
2) Create a new `planning slot`
3) click on any `template id`
4) Now remove the `end date`
5) A traceback occurs

Error:-
```
TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.datetime'
```

When the user removes the `end datetime` its value is `False` 
which leads to the above traceback when `-` is used between `start` and `end` datetime.

https://github.com/odoo/enterprise/blob/5600b5b754f79e5d7a253fe9db45ac8a9273d3de/planning/models/planning.py#L406-L408

Additionally, a `value error` is also occurring when the `start` date-time is empty,
while calculating start-end-dates with `template` .  As it returns both `datetime` and timezone.

From the below lines `tzinfo` only removes when the start date time and template is present. 

https://github.com/odoo/enterprise/blob/5600b5b754f79e5d7a253fe9db45ac8a9273d3de/planning/models/planning.py#L621-L627

After applying this commit will resolve both issues and make the code more robust

sentry-5005245970

Forward-Port-Of: odoo/enterprise#61024

This traceback occurs when the user makes the `end date` as empty while 
creating a new planning slot with template.

To reproduce this issue:

1) Install planning
2) Create a new `planning slot`
3) click on any `template id`
4) Now remove the `end date`
5) A traceback occurs

Error:-
```
TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.datetime'
```

When the user removes the `end datetime` its value is `False` 
which leads to the above traceback when `-` is used between `start` and `end` datetime.

https://github.com/odoo/enterprise/blob/5600b5b754f79e5d7a253fe9db45ac8a9273d3de/planning/models/planning.py#L406-L408

Additionally, a `value error` is also occurring when the `start` date-time is empty,
while calculating start-end-dates with `template` .  As it returns both `datetime` and timezone.

From the below lines `tzinfo` only removes when the start date time and template is present. 

https://github.com/odoo/enterprise/blob/5600b5b754f79e5d7a253fe9db45ac8a9273d3de/planning/models/planning.py#L621-L627

After applying this commit will resolve both issues and make the code more robust

sentry-5005245970

Forward-Port-Of: odoo/enterprise#61024

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank.

UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/payments-and-reporting/insidebusiness-payments/domestic-uk-file-format-description-february-2024.pdf that this identifier should be 999999 + 4 blanks or SUN + 4 blanks, so we make the choice to use 999999 if we have no SUN, for HSBC.

We don't want to make the SUN field optional for everyone just because of that one use case. Instead, we ask people to write 'HSBC' as their SUN number in the settings if they don't have any, and this considers the field as blank for the file generation.

(HSBC's doc can be found on the related ticket)
opw-3863262

Forward-Port-Of: odoo/enterprise#62224
Forward-Port-Of: odoo/enterprise#62111