Steps to produce:
---
- Install `sales` module.
- Go to Settings and enable `Units of Measure and Packaging`.
- Set a long name for `units` UoM.
- Create a Sale Order and add a product via the catalog.

Issue:
---
- Long UoM names are not fully visible in the catalog view.

Root cause:
---
- The outer `<div>` has `d-flex` but lacks `w-100`, causing it to overflow
  its container.

Solution:
---
- Added `w-100` to the outer `<div>` to prevent overflow.
- Adjusted the quantity selector layout for better visibility.

Before:
---
<img width="388" height="141" alt="image" src="https://github.com/user-attachments/assets/dafae08a-3c9d-4163-8894-daa2e4d26f62" />

After:
---
<img width="382" height="154" alt="image" src="https://github.com/user-attachments/assets/abd6f034-be4b-49bf-be9c-c9779de0f30d" />

Enterprise PR: https://github.com/odoo/enterprise/pull/121139

opw-6253382

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

## Issue
When filtering projects using the "Timesheets >100%" filter, some projects with negative remaining hours (and with their `is_project_overtime` field set to True) won't be displayed, even though their expected hours are completed.

This happens with projects which have tasks set to the "Done" or "Cancelled" state. The timesheets entries in those tasks are not taken into account when searching using the "Timesheets >100%" filter.

## Steps to reproduce
1. Install *Task Logs* (`hr_timesheet`)
2. Create a Project P (with Timehseets enabled)
3. Set the allocated hours of the project to 3:00 (3 hours)
4. Create two tasks:
    - T1: State "In progress", and one timesheet entry of 2:00 (2 hours)
    - T2: State "Done", and one timesheet entry of 2:00 (2 hours)
5. Back to the project view, set the filter to "Timesheets >100%"
6. **Project P is not shown, even though the total time spent on the project is 4 hours, completing the allocated hours set on the project.**

## Cause
The `_search_is_project_overtime` method filters out the tasks in "closed" states (Done/Cancelled) when computing the amount of time spent on the project.

https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L103-L114

This does not match with the behavior of the `_compute_is_project_overtime`, which does not take into account the state of the tasks to determine the value of the field:

https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L85-L94

This leads to a confusing behavior, where a project can have its `is_project_overtime` field set to True, but will still not be shown when using the "Timsheets >100%", even though that filter is defined as `[("is_project_overtime", "=", True)]`.

The compute method was updated by https://github.com/odoo/odoo/commit/d4252825f52a3172420dcda0ea394e42da9f8853, but the related search method was left unchanged, leading to this slight incoherence between the two methods.

opw-6422173

Forward-Port-Of: odoo/odoo#282098
Forward-Port-Of: odoo/odoo#281997

_(updates on July-17th and July-28th for points 2. and 3. in `hr_expense`)_

# Introduction
**1\.** A fix to `hr_org_chart` was initially proposed.
I think it is mergeable because it fixes the user-experience properly like expected in Odoo standard.

Other commits are suggested to `hr_expense`.
They were designed to allow more flexibility in the management of `hr_employee.company_id` (in multi-company context) and allow not to duplicate the `hr.employee` of each companies of the `res.users`.
**2\.** The [FIX] silences a multi-company access error when searching for Expense validators => it seems safe
**3\.** The [IMP] largely allow more flexibility for a "Expense: Team Approver" when creating expenses on behalf of its subordinates

# 1. in hr_org_chart [FIX]
Prevents multi-company error when recursively searching for ancestors.

<img width="1035" height="789" alt="image" src="https://github.com/user-attachments/assets/d5517f79-7efc-4223-ae77-0af8b25a3d1e" />

### Issue description

In a multi-company environment, when one of the `hr_employee.company_id` of a hierarchy is not in the allowed companies of a Manager's `res_users.company_ids`, this Manager can view `hr.employee` in the list view but cannot open their forms.

This happens when:
- `hr_org_chart` module is installed
- the Org Chart is displayed on the 1st page of the `hr.employee` form, like when the HR settings "Skills Management" is disabled (in `res.settings`) => thus the whole form becomes inaccessible from the manager

When a `hr.employee` form is opened, a multi-company access error is thrown to him, even if the `company_id` of the opened `hr.employee` is in the user's `res_users.company_ids`, because of the hierarchy's `company_id`.
It should be expected that the part of the Org Chart which is not allowed to be seen would just be hidden. 

### Steps to reproduce
Data setup:
- Employee "A" in company A
- Manager "M" in company A, manager of "Employee A"
- Manager of manager "MM" in company A, manager of "Manager M"
- And now, in company B (let's say a Holding), the "Director" is manager of "Manager MM"
- "Manager M" is only given access access to Company A
- the module "hr_org_chart" is installed

Actions:
- Login with Manager M
- Browse to Employees list and try and open the form of "Employee A" (up to tab _"Professional information"_, if it is not the 1st of the notebook)

### Proposed fix

This PR re-uses the already existing method `_check_employee` which contains all the logic to solve the issue. Maybe the call to this method was forgotten?
This PR simply call this method when finding an ancestor, in the controller of `hr_org_chart`. This fix is thus very limited to the call to the public method `hr_org_chart.get_org_chart()` made by the Org Chart widget.

### Desired behavior after PR is merged

The part of the Org Chart not allowed to be seen by "Manager M" is hidden.


# 2. hr_expense [FIX]

<img width="541" height="415" alt="image" src="https://github.com/user-attachments/assets/d594815b-2b77-4088-878b-9b192b64d6a3" />

### Issue description
As an employee, I click on the button "View Report" on my expense.
I get a multi-company access error, preventing me to view and edit my expense report.
This is because the manager of the department I belong is in a company I'm not allowed to see.

This can also happen just when opening my Expense (instead of Expense Report).

### Current behavior before this PR
The employee is blocked to continue editing its Expense or to submit it to a Report.

### Current behavior after this PR
The employee can edit and submit its Expense no matter the `company_id` of its hierarchy.
Technically: the `can_approve` field on the expense sheet uses a localized `.sudo()` method to bypass multi-company limits when searching if the current user is a validator.



# 3. hr_expense [IMP]

<img width="1028" height="549" alt="image" src="https://github.com/user-attachments/assets/1096c0d4-d025-46a9-8559-6bab5de71577" />

### Improvement summary
In multi-company environment, allow a "Expense: Team Approver" to create Expenses for its subordinates (`hr_expense.employee_id`) **no matter the `hr_employee.company_id` of its subordinates**.
The domain of `hr_expense.employee_id` keeps the security of `check_company=True` => thus the Manager only sees `hr.employee` having their `company_id` in the manager's allowed companies (`res_users.company_ids`).

### Current behavior before this PR
Context: a 8-companies environment where the `hr.employee` of each hierarchy chains are splitted in many different companies, like:
- top-level (admin board): 1 company
- middle management: approx. 2 companies
- down level: the other companies
The "down level" have `hr.employee` but no `res.users`. The "middle management" have `res.users` and must create the Expenses of their "down level" subordinates on their behalf.

Issue: as a manager, as per Odoo proposal, I need to have a `hr.employee` in the same company of my subordinates to be able to create Expense of their behalf.
However, this is very inconvenient because as a Manager, I can have employees in various companies. And my own manager it not in the same company than me, so the same issue applies recursively.

### Behavior after this PR is merged
The domain of the field `expense_id.employee_id` is more permissive. As a Manager, it allows me to select the Employee I manage in my active company, no matter if I have or not myself a `hr.employee` in this company.

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

Forward-Port-Of: odoo/odoo#266261

### Issue before this commit:
When generating an electronic invoice (e.g., ZUGFeRD/Factur-X) with a 0% tax from a non-EEA supplier (e.g., Switzerland) to an EEA customer (e.g., Germany), the XML tax <ram:CategoryCode> is incorrectly set to 'E' (Exempt) instead of 'G' (Export).

### Steps to reproduce the issue:
1. Download Accounting and l10n_ch
2. Set the VAT for the CH company
3. Create an invoice for a German customer with 0% tax setted (for which you have to set as electronic invoicing the ZUGFeRD template into the Accounting tab of his contact)
4. Send it and see that the tag <ram:CategoryCode> is setted as E instead of G

### Cause of the issue:
The logic assigning the 'G' and 'K' tax category codes was only triggered if the supplier was located within the EEA. If the supplier was outside the EEA, the code bypassed this block entirely and fell back to the default 'E' code for 0% taxes.

### Reason to introduce the fix:
Update the condition to trigger when either the supplier or the customer is in the EEA. This ensures that cross-border transactions involving at least one EEA party correctly evaluate and apply the 'G' (Export outside the EU) category code.  Also the case supplier not in eea with VAT filled in + customer in eea + RC tax with amount != 0 is fixed now (letter G reported instead of S).

### Documentation:
[eInvoicing technical guidance document_v1.pdf](https://github.com/user-attachments/files/30831749/eInvoicing.technical.guidance.document_v1.pdf)


opw-6407399

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

Forward-Port-Of: odoo/odoo#282189
Forward-Port-Of: odoo/odoo#281245