Steps to reproduce:
------------------------------
1. Install Subscription module
2. Create a new subscription and confirm it
3. Create an invoice from the subscription.
  * Register a payment and ensure the invoice is in the Paid state.
4. Go back to the subscription and close it with any reason
5. Open the related invoice.
  * Create and Confirm Credit Note.
  * Register a payment for the credit note.
6. Go back to subscription

Observation:
------------------------------
The subscription is automatically set back to `In Progress` even  though it was previously churned.

Issue:
------------------------------
The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid.

Solution:
------------------------------
Add a condition to exclude refund invoices from the reopening logic

opw-5947999

Forward-Port-Of: odoo/enterprise#108487

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#102335

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#105115