### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.

### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?

### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67

### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.

opw-6050537

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

### Issue:
If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags

### Cause:
The `_get_payments_vals` method, `InstrId` is based on the payslip ID
When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers
https://knowledge.xmldation.com/support/iso20022/general_rules/instrid

This commit adds a unique suffix (e.g., -1, -2) to the `InstrId` for each transaction generated from the same payslip to ensure technical uniqueness Nothing change when you only have one account

This is the part of the code that use the payment name:
https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299

### Steps to reproduce:
- Install `hr_payroll_account_iso20022` with demo data
- On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number`
- Open the Employee page for Abigail Peterson
- In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any)
- Click on Salary Allocation and Save (You'll have a 50/50 ratio)
- Create a new Pay Run (for Abigail Peterson)
- Open the last PaySlip and Validate
- Create Payment Report (Export Format: SEPA)
- Download the Payment Report and check the <InstrId> tags

opw-6069670

Forward-Port-Of: odoo/enterprise#113113

The crm_iap_mine module extended the crm tour, by adding steps to introduce the lead generation feature. These steps were inserted in the middle of the tour, which caused the tour to backtrack and loop on itself.

Why?
For the tour to wait for the next step, we specify the selectors it should look for. In this case, because the modal redirects to the same page (with an updated domain), we cannot specify a selector that would be unique to the new page -> the target is found before the redirect -> after the redirect happens, the tour backtracks to try and recover, causing the loop.

Moving the steps to the end of the tour fixes the issue.

The disadvantage of this is that no the last step of the tour is not deterministic - it can fail if the user selects a combination of countries and industries which have no valid leads (Antarctica...) or if the user doesn't have enough IAP credits. In this case, the 'Congrats' rainbowman is shown even if the generation failed.

Task-5386684

Forward-Port-Of: odoo/odoo#249733

Currently, an error occurs when sending the password reset link to multiple users.

**Steps to Reproduce:**
 - Install `auth_signup` module.
 - Go to `Users` and make sure there are at least two user records.
 - In the `list view`, select both users.
 - Go to `Actions` > click `Send Password Reset Instructions`.

`ValueError: ValueError('Expected singleton: res.users(24, 23)') while evaluating 'records.action_reset_password()'`

This error occurs when generating the email body_html [1]. It passes multiple user 
records (self) as the context record, but _render_encapsulate expects a single user 
record to render the email body. which raise the error here[2].

This commit passes a single user record when rendering body_html.

[1]: https://github.com/odoo/odoo/blob/39c6e3a2578c4f7058dddb6acf12231d8716e7fd/addons/auth_signup/models/res_users.py#L214

[2]: https://github.com/odoo/odoo/blob/39c6e3a2578c4f7058dddb6acf12231d8716e7fd/addons/mail/models/mail_render_mixin.py#L187

sentry-7271437735


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

This error occurs when the schedule pay is removed from an employee contract with a defined wage.

Steps to reproduce:
- Install `l10n_au_hr_payroll` module with demo data
- Switch to `My Australian Company`
- Open any Employee > Payroll > `Wage` remove `schedule pay`

Traceback:
```py
 File "/home/odoo/src/enterprise/saas-19.2/l10n_au_hr_payroll/models/hr_version.py", line 549, in _compute_wage
    version.wage = Payslip._l10n_au_convert_amount(daily_wage, "daily", version.schedule_pay)
  File "/home/odoo/src/enterprise/saas-19.2/l10n_au_hr_payroll/models/hr_payslip.py", line 511, in _l10n_au_convert_amount
    coefficient = PERIODS_PER_YEAR[period_from] / PERIODS_PER_YEAR[period_to]
KeyError: False
```

We are encountering this error because the `schedule pay` is removed, causing the field to become `False`. This False value is then passed to the `_l10n_au_convert_amount` [method], resulting in a `KeyError`.

[method]: https://github.com/odoo/enterprise/blob/92c584cc1426ac70f6f77aa8216c17004fa42d35/l10n_au_hr_payroll/models/hr_payslip.py#L500-L509

sentry-7401189447

Forward-Port-Of: odoo/enterprise#113623

Currently, an error occurs when the user removes the scope of the emission source.

**Steps to Reproduce:**
 - Install the `esg` module.
 - Create an `emission source` record or open an `existing one`.
 - Remove the `scope` value and click anywhere.

`ValueError: Compute method failed to assign esg.emission.source(<NewId origin=1>,).activity_flow_direct_indirect`

**Cause:**
 Error started occurring in 19.0 due to a change in selection field behavior. Since from [commit](https://github.com/odoo/odoo/pull/214422/commits/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef), selection 
fields no longer display an “empty” value. To remove a value from a selection field, the user must clear the 
field, similar to a many2one field.
when the user removes the scope value, The system attempts to compute the activity flow, 
but since the scope is False, it does not match any case [1]. As a result, the method fails to 
assign a value to activity_flow_direct_indirect, raising an error.

This commit ensures that the activity flow and activity flow direct indirect are initialized to False. If no 
condition matches, the field remains False, preventing the assignment failure.

[1]: https://github.com/odoo/enterprise/blob/eaf4b7559b8eb6c538820d6e54f583a41077ac3d/esg/models/esg_emission_source.py#L79-L89

Forward-Port-Of: odoo/enterprise#114079

**Issue:**
When a user posts a credit note with a currency exchange difference relative to the reversed move,
the resulting exchange move lines lack the mandatory analytic distribution.
This triggers a validation error, preventing the credit note from being posted.

**Steps to reproduce:**
- Set "mandatory" applicability on any analytic plan.
- Set two different currency rates on two different dates for any foreign currency.
- Create and post an invoice on the first date (ensure the mandatory analytic distribution is set).
- Create a credit note from that invoice using the second date.
- Click on the post button on the credit note.

Result: A validation error occurs even though the credit note itself has the mandatory analytic plan set,
because the auto-generated exchange move does not.

**Fix:**
Since the context key validate_analytic is set to True by the post button action,
it must be manually set to False during the automatic creation of exchange difference moves to bypass the mandatory plan check.

OPW-6081632

Forward-Port-Of: odoo/odoo#259624
Forward-Port-Of: odoo/odoo#259381

1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)

To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
    result = func()
             ^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
    edi_users._peppol_get_message_status()
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
    processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
    peppol_response = uuid_to_record[uuid]
       ^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```

task-None

Forward-Port-Of: odoo/odoo#259834