__

## Short functional explanation of the error
Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours.

As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours.

## Reproduction Steps
1. Go to Planning. Click on Configuration tab > roles.
2. Create a role and add an employee as a resource This employee has to have a fixed working schedule.
3. Click on Configuration tab > Shift Templates.
4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created.
5. Click on Schedule tab > By resource and click on New.
6. Select the role you just created.

### Expected behavior
The start and end hours should align with the shift template start and end hours.

### Unexpected behavior
The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36.

## Origin of the issue
We kept computing the working intervals of employees, even if a shift template was set:
https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule.
__
opw-5898509

Forward-Port-Of: odoo/enterprise#107018

**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.

**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.

**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.

**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.

opw-5902414

Forward-Port-Of: odoo/odoo#247737

**Steps to reproduce:**
* Install `Accounting` and `accounting_peppol` modules.
* Create Belgium company.
* Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`.
* Create and post a customer invoice.
* Click **Send & Print**.
* Select only **Email** and click **Send** to generate the PDF.
* Click **Send & Print** again.
* Select only **Peppol** (partner configured for Peppol).
* Click **Send**.

**Observed behavior:**
* The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF.
* The receiver gets the XML data without the PDF representation.

**Cause:**
* When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it.
* The PDF embedding into the UBL XML relies on this post-processing step.
* Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic.

**Fix:**
* When sending via **Peppol**, detect if a PDF already exists on the invoice.
* If so, explicitly post-process the UBL XML to embed the existing PDF before sending.
* Ensures the PDF is always included in Peppol messages, regardless of when it was generated.

opw-5495465

Forward-Port-Of: odoo/odoo#245901

When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account.

Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient.

The `partner_bank_id` can be assigned through different processes:

- If the wizard has only one batch:

The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`.

- If there are multiple batches:

Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id'].

The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly.

I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are.

-Previous PR : [242863](https://github.com/odoo/odoo/pull/242863)

However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here.

Ticket: opw-5401372

Forward-Port-Of: odoo/odoo#249537
Forward-Port-Of: odoo/odoo#246558