Steps to reproduce:
- German PoS with Fiskaly TSS configured
- Set a customer that is an address contact (type invoice/delivery/other) on an order; such a contact has no name of its own, it is displayed with its parent's
- Close the session

Issue:
Closing crashes with "TypeError: 'bool' object is not subscriptable" and the session cannot be closed at all.

Cause:
_get_dsfinvk_cash_point_closing_data builds the DSFinV-K buyer block from partner.name, which is only guarded by "if partner := o.partner_id". res.partner.name is not required: the res_partner_check_name constraint only enforces it for type='contact', so an address contact stores NULL there and partner.name reads as False, which cannot be sliced.

Fix:
Fall back on complete_name - what the UI displays for those contacts, "Parent Company, Delivery" - and on a literal when even that is empty, since the buyer name is mandatory in the export. Reading name first leaves the exported value untouched for every partner that has one.

opw-6518336

Forward-Port-Of: odoo/enterprise#131212
Forward-Port-Of: odoo/enterprise#129709

### Issue before this commit:
Generating a SEPA Credit Transfer XML for certain European banks (e.g., Austrian and German banks) fails because the generated XML contains an unexpected `<CtrySubDvsn>` tag inside the `<PstlAdr>` node, leading to the rejection of the batch payment file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_at
2. Go to settings and activate SEPA Credit Transfer / ISO20022
3. Go to Journals > Bank > set an account number
4. Create an austrian contact (ex. FK Austria Wien AG) and set in the invoicing tab a bank (ex. AT526000071856851733) and set it trusted
5. Go to Bills, create a new one with the contact created and confirm it
6. Then click 'PAY' and select SEPA Credit Transfer
7. Go to Vendors > Batch Payments
8. Create a new one with:
	1. Bank as bank
	2. SEPA Credit Transfer as Payment Method
	3. Add the bill just created
9. Validate and download the XML
10. See that a wrong tag <CtrySubDvsn> is added. This makes some banks refuse it

### Cause of the issue:
External commit 30b023d394a5e4de64873188aa1d5961fecccb10 introduced the `<CtrySubDvsn>` tag to support US and CA requirements. However, the change was incorrectly applied to the common `account_iso20022` file, making it leak into standard European SEPA exports where the tag is not compliant with certain strict banking validation rules.

### Reason to introduce the fix:
Revert the generic addition of the `<CtrySubDvsn>` tag in the common ISO20022 XML generation and restrict it only to the specific localizations (US/CA) that require it. This brings the `<PstlAdr>` node back to compliance, allowing Austrian, German, and other European banks to successfully process the files.

opw-6523035

Forward-Port-Of: odoo/enterprise#131156
Forward-Port-Of: odoo/enterprise#131090

It is a functional request to add him to the groups even if he is not
involved by a functional access.

[FIX] base: prevent group desync in user onchange

When editing a user in the web client, the onchange mechanism creates a
virtual record using `new(values, origin=record)` to build the baseline
snapshot used for field diff tracking.

In `res.users.new()`, logic automatically adjusts `group_ids` (adding or
removing `base.group_multi_company` depending on the number of companies
on the user) as a side effect. When `new()` was called with an `origin`,
this side effect corrupted the reference snapshot. Consequently, the
onchange return value failed to detect or report the real delta to the
web client, leaving the UI in an incorrect or desynchronized state (e.g.
`role` radio buttons or access right checkboxes out of sync with actual
groups).

Fix this by skipping the automatic group adjustment in `new()` when
`origin` is present, keeping the reference snapshot clean.

Add tour tests to ensure `role` and group checkboxes stay synchronized
across saves and page reloads in the web client.

Issue:
The calendar multi-create popover retains its form values so they can be reused when adding entries to another selection. In a variable working schedule, this retained state incorrectly restricted Time Type to the first allowed value after mass creating entries and deleting one occurrence.

Refreshing the page restored all Time Type options because the form was then rebuilt from the complete backend value of `allowed_work_entry_type_ids`.

Steps to reproduce:
- Open a working schedule and switch it from Fixed to Variable.
- Select multiple days and mass add working-time entries.
- Select one of the created days and delete its entry.
- Select that day again and open the Add popover.
- Open Time Type and observe that only the first allowed type is available.
- Refresh the page and observe that all allowed types are available again.

Cause:
`work_entry_type_id` is filtered by the computed `allowed_work_entry_type_ids` relation. The relational model keeps every relation ID in `StaticList.currentIds`, but only materializes the loaded page in `StaticList.records`. Since this invisible domain dependency has no related display fields, its loaded page is limited to one record.

When the multi-create popover was submitted or closed, 

https://github.com/odoo-dev/odoo/blob/23266b3a3bf0856dc147e3780e5ac54469bbcc53/addons/web/static/src/views/view_components/multi_selection_buttons.js#L169-L180

serialized x2many values from `StaticList.records`. This reduced `allowed_work_entry_type_ids` to its first loaded ID in the retained `multiCreateValues`. Reopening the popover reused that incomplete relation, so the Time Type domain correctly evaluated against only one ID.

Solution:
Serialize x2many values from `StaticList.currentIds` so every related ID is preserved. For loaded records, merge the cached record data to retain edited or display values, for unloaded records, retain an ID-only value.

This keeps the complete domain dependency across calendar multi-create popovers without changing the backend Time Type computation.

opw-6398706

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

Forward-Port-Of: odoo/odoo#280391

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
    - for duration based calendars, morning and afternoon map to 12 hours of availability and full day maps to 24 hours of availability
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

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

Forward-Port-Of: odoo/odoo#287019
Forward-Port-Of: odoo/odoo#258604

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
    - for duration based calendars, morning and afternoon map to 12 hours of availability and full day maps to 24 hours of availability
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

Forward-Port-Of: odoo/enterprise#130714
Forward-Port-Of: odoo/enterprise#113498

Issue:
Colombian child contacts linked to a NIT company are displayed with their standalone name instead of "Company, Contact". Searching Contacts by the company name consequently returns the company but not its child contacts.

Steps to reproduce:
- Create a Colombian company with NIT
- Add a child contact or address to that company
- Filter Contacts by the company name
- Observe that the child is displayed separately and is not returned

Cause:
The Colombian `is_company` computation classifies every partner with a Colombian NIT and qualifying obligations as a company: https://github.com/odoo/enterprise/blob/911686a31d5d3c1539d0dff7d16edf1ce9b101ca/l10n_co_edi/models/res_partner.py#L43-L53

Those fiscal values are commercial fields and are propagated to child contacts. Without checking that the partner is its own commercial entity, children are therefore classified as companies, preventing the standard display name logic from prefixing their parent name.

Solution:
We need to restrict the Colombian company classification to partners that are their own commercial partner. This preserves the NIT and obligation rules for actual companies while keeping their inherited child records as contacts, restoring both the combined display name and parent name search behavior.

opw-6470958

Forward-Port-Of: odoo/enterprise#130373
Forward-Port-Of: odoo/enterprise#128986