When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#124096

#### Issue

When manually adding component lines in the subcontracting Record Production flow, extra stock move lines can remain in the database without a linked stock move.

Those lines have no move_id, so their related state is empty. They can later be selected by stock reservation code and cause validation errors when processing the transfer.

#### Steps to reproduce

1. Create a subcontracted product.
2. Confirm a subcontracting receipt/purchase flow for that product.
3. Open the subcontracting Record Production popup.
4. Remove an existing component line.
5. Add a new component line for another storable product available at the subcontractor location.
6. Save/record the production.
7. Check stock.move.line records ,  Inventory > History > Group By Status.

An extra stock move line is left with no move_id.

#### Root cause

The inverse of `mrp.production.move_line_raw_ids` already collects and deletes move lines detached from existing raw moves.

However, when the user adds a new component product, the inverse creates a new additional raw move. Creating that raw move can also create reserved move lines. The inverse then replaces `move.move_line_ids` with the user-entered lines, but it did not collect the newly created reserved lines before replacing them.

Those reserved lines were detached from the move and left in the database as orphan stock move lines.

#### Fix

Apply the same cleanup logic to newly created additional raw moves: collect their auto-created move lines before replacing `move_line_ids`, then unlink those detached lines at the end of the inverse.

opw-6304649

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

Forward-Port-Of: odoo/odoo#276235

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details
- Go to my/account page.

Issue:
- Peppol related details always displayed on `my/account` page even though user select different invoice sending method like: `By Email`.

Casue:
- selector to manage visibility of Peppol related details in `my/account` is wrong and because of that those fields always display. Probably because https://github.com/odoo/odoo/pull/195764 and backport of this https://github.com/odoo/odoo/pull/198327 merged at same time.

Fix:
- Update selector to fix this

### [FIX] account_peppol: fix error when setting wrong endpoint

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details.
- Go to my/account page.
- Set some wrong Peppol value for `Peppol e-Address (EAS)` or `Peppol Endpoint` or `Electronic format`.

Issue:
- Not able to save those details without any error message on address page and getting error on console `Cannot read properties of undefined (reading 'classList')`.

Casue:
- In this PR https://github.com/odoo/odoo/pull/190312 when adapting portal page we set not existing fields in `invalid_fields` details and because of that it can't find related fields on address page and don't allow to save details without raising proper error message.

Fix:
- Updated `invalid_fields` values to properly target them

### [FIX] account_peppol: fix display issue for peppol related fields in address

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

Forward-Port-Of: odoo/odoo#276905

- Compute the standard durations for all French leaves in a single
  `_get_durations()` call instead of recomputing them for each leave.

- Reuse the precomputed duration mapping while calculating the French
  legal duration for each leave.

- Keep the existing French-specific duration calculation unchanged,
  including public holidays, company calendar, date extension, and
  half-day handling.

This avoids repeated ORM computations when processing multiple French
leaves in a batch and significantly improves the performance of leave
duration computation.

Performance testing was performed using the `hr.leave.employee.report`
introduced in 19.1, which calls `_get_durations()` on a large batch of
virtual leaves.

Performance testing on a database containing 677 leaves, including
298 French leaves:

| Metric                              | Before          | After       |
|------------------------------------|-----------------|-------------|
| Standard duration computations    | 298             | 1           |
| Total `_get_durations()`          | >169s (timeout) | ~24s        |

not specific to the employee report and benefits
any caller that invokes _get_durations() on a larger batch.

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

Forward-Port-Of: odoo/odoo#281165