**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#99784

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619

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

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

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