Steps to reproduce
==================
1. Enable an express checkout provider on the shop, e.g. Stripe with Link.
2. Sign in as a customer having a saved address, then put a deliverable product in the cart.
3. Pay with the express checkout button, confirming a shipping address that differs from the saved one. Address validation does it on its own by completing a zip code, e.g. 61820 becomes 61820-1234.

=> The order's delivery and invoice addresses read "Anonymous express
   checkout partner for order S00xxx", and so do the delivery slip and
   the shipping confirmation email.

Root cause
==========
When the received shipping address matches none of the customer's contacts, `express_checkout_process_shipping_address` creates one to hold it. As the payment form has yet to send the customer information, that contact is named after the order [1].

`process_express_checkout` then completes it with the address of the payment form [2]. Express checkout wallets don't necessarily send a recipient name, and Stripe Link never does, so the placeholder name is left untouched. It remains on the order, which uses that contact as its invoice address too when both addresses match.

Fix
===
Fall back on the billing name, then on the customer's own name, when the shipping address holds no name.

[1]: https://github.com/odoo/odoo/blob/18.0/addons/website_sale/controllers/delivery.py#L197-L206
[2]: https://github.com/odoo/odoo/blob/18.0/addons/website_sale/controllers/main.py#L1677-L1684

opw-6366612

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

#### [FIX] account: invoice edi format selection placeholder
The placeholder of the field "eInvoice format" (`invoice_edi_format`)
is confusing currently.
It says "XML format". It is unclear to the user what this means / will do.
This commit changes it to "Automatic Selection".

This better reflects what is happening:
If no value is selected for the field (= the placeholder is selected
in the UI) we try to automatically select a value.
(See `_compute_invoice_edi_format` / `_get_suggested_invoice_edi_format`
on model 'res.partner')

#### [FIX] account_peppol: disallow disabling services
Currently it is possible to disallow any services in the configuration.
This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0".

1. Ensure Peppol is activated (test mode or production; not demo)
2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services
3. Any service can be disabled.

This commit hides the button to open the service wizard.
(Also in the wizard it is now not possible to disable services anymore.)

#### [FIX] account: generation of print-related entries in cog menu
Before this commit:
The dynamic generation of the print related entries in the cog menu
does not work correctly.

Problem / Solutions:
There is a check in the javascript that does not work as intended.
Thus the entries are not added to the cog menu in all cases.
The check was intended to only block it for "new" records (not saved yet);
to avoid issues in case the move has no id yet.
After this commit we just check the id directly.

#### [FIX] account: explicit local format

Explicitly separate the suggested "eInvoice format" into
local format (intra-country) and other (inter-country).

This is done by adding the following functions to
`_get_suggested_invoice_edi_format`:
- `_use_local_invoice_edi_format`: Checks whether the partner is from
  the same country as the company.
- `_get_local_invoice_edi_format`:
  The function that can be extended for every country to specify
  the local format.

#### [FIX] account: generic extra print items
Before this commit:
It is not possible to explicitly generate XML files in BIS 3.0 or
local formats.

This commit adds the following formats to the "Download" item in
the cog menu:
- the "eInvoice format" (field; `invoice_edi_format`)
- local format (from function `_get_local_invoice_edi_format()`)
- suggested format (from function `_get_suggested_invoice_edi_format()`)

All formats are labeled with their name (so e.g. "Xrechnung CIUS";
and not "Local Format")

In case the file can not be generated we log the errors in the chatter.

The "XML UBL" button was renamed to "XML Attachment (UBL/CII)".
This avoids confusion with the new buttons.
The aforementioned button downloads any existing UBL attachment (from field `ubl_cii_xml_id`).

#### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format
Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce .
There we improved the eInvoice format labels for clarity.
But 2 label were formatted differently than the others.
This commit fixes that.

#### References
task-4737164

### Steps to Reproduce:
1. Activate Peppol
2. Create invoice for customer with Peppol
3. Add line without product name or label
4. Send invoice through Peppol and observe the Traceback error

### Issue:
When generating a Peppol invoice, there will be a Traceback error if an invoice line is missing both a product and a label. The XML builder evaluates the missing `cbc:Name` element as `None` instead of an empty dictionary. Therefore, attempting to directly subscript `['_text']` on it throws a TypeError traceback. This prevents the user from seeing the standard validation warning about the missing item data.

### Solution:
We can update the document node constraint check to safely access the dictionary keys using `.get()` with an empty dictionary fallback. This prevents the traceback and ensures that the system will correctly display the intended validation error to the user.

opw-6577441

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

Issue:
On the Mexican localization, setting a contract with a monthly wage (e.g. MXN 20,000) together with a weekly payable structure showed the wage labelled as "/ semana". The generated payslip then displayed the full 20,000 on the worked days input, making it look like the weekly period was not prorated.

Steps to reproduce:
- Install the l10n_mx localization
- Set a contract with a monthly salary of MXN 20,000 and a weekly schedule
- Generate a payslip and open the worked days lines

Cause:
The wage caption on the contract form is driven only by schedule_pay, so a weekly schedule renders "/ semana". In this version the payroll engine has no MX-specific proration and consumes the contract wage as a monthly base (the amount computation divides by the period's own worked hours). The label therefore contradicts how the value is actually used. https://github.com/odoo/enterprise/blob/5f9cf56372a7faa1bce55c418454d3aacbff04c4/hr_payroll/views/hr_contract_views.xml#L36-L48

Solution:
Force the wage to always be shown as a monthly amount for Mexican contracts and hide the schedule-based period suffixes. This aligns the displayed label with the monthly base the engine requires, without altering how wages or worked days are computed.

opw-6535787

**Steps to reproduce:**
* Install `l10n_ec_reports_ats`.
* Create a parent company with an Ecuadorian RUC.
* Create a branch/sub-company under that parent (sharing the same RUC).
* Post invoices under both the parent and the branch company.
* Open the ATS report (Report 104) from the parent company and export the ATS XML file.

**Observed behavior:**
* The generated ATS XML only includes invoices whose `company_id` matches the parent company exactly.
* Invoices posted under the branch company are silently omitted, even though the branch shares the same RUC.

**Cause:**
* `_get_sale_values`, `_get_purchase_values`, and `_get_void_moves` all filtered `account.move` and `account.journal` records using `('company_id', '=', company.id)`.
* In Odoo, branch companies share the parent's journals but invoices carry `company_id == branch.id`.  The strict equality filter excluded all branch invoices.
* `_get_internal_vat_tax` similarly filtered `account.tax` by the parent company only, missing taxes associated with branch invoices.
* `branch_allowed` was not set on the report options, preventing the UI from offering branch selection.

**Fix:**
* Collect all companies sharing the same RUC via `company._get_branches_with_same_vat(accessible_only=True)`.
* Replace every `('company_id', '=', company.id)` domain clause with `('company_id', 'in', company_ids)` across journal, move, and tax lookups so that records from all same-RUC branches are consolidated.
* Set `branch_allowed = True` in `_custom_options_initializer` to align the report options with multi-branch behaviour.

opw-6504463

Issue: 
-
Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.

Cause:
-
The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies.

Fix:
-
The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view.
The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given.

Steps to reproduce:
-
1. Create Company A and Company B.
2. In Company B, create a public holiday on Tuesday.
3. Switch back to Company A.
4. Open the All Timesheets Grid view from Company A.

Expected behavior:
-
- The grid column for Tuesday should not be grey for Company A users.

Current behavior:
-
- The grid column for Tuesday is grey, incorrectly showing it as a time-off day.

task:4492966

Forward-Port-Of: odoo/enterprise#88495