*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us

When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.

For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron

Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std

ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
    <field name="name">United States: Employee</field>
    <field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
    <field name="country_id" ref="base.us"/>
</record>
```

The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.

sentry-7166574553

**Problem:**
When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.

**Steps to reproduce:**
1. Go to Settings app and enable debug mode
2. Navigate to Technical → Reports
3. Search for "slot_report"
4. Click "Add to print menu" button
5. Refresh the browser
6. Go to Planning app and switch to list view
7. Select a few planning.slot records
8. Click Print → Planning

**Current behavior:**
A blank or invalid PDF is generated.

**Expected behavior:**
Users should receive a clear error message directing them to use the correct print method from the calendar view.

**Cause of the issue:**
The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports.

**Fix:**
Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data.

opw-5477184

[FIX] account_reports: journal audit tax display

**Problem:**
The tax summary tables in the Journal Audit report overflow and collide
when displaying large monetary amounts (9+ digits).

**Steps to reproduce:**
1. Create and post invoices/bills with large amounts (e.g. 999,999,999)
2. Go to Accounting > Reporting > Audit Reports > Journal Audit
3. Observe the tax summary tables overflow their columns

**Current behavior:**
Large numbers overflow and collide because the sub-tables use
`table-layout: fixed` and are placed in separate `<td>` elements with
hardcoded `colspan`, preventing them from adapting to content width.

**Expected behavior:**
The tax summary tables should adapt their widths to accommodate large
monetary amounts without overflow or collision.

**Cause of the issue:**
Several layout issues combined to waste space and cause overflow:
- The sub-tables were in separate `<td>` elements with fixed `colspan`
  values (2 and 5), unrelated to actual content width
- `table-layout: fixed` forced thin columns (e.g. country code) to take
  equal space as wider columns (amounts), causing larger values to
  overflow
- The "Taxes Applied" header colspan used `taxesByCountry.length` which
  doesn't work on objects (always undefined), so the header never
  spanned the full width in multi-country scenarios
- Full country names (e.g. "United States") consumed unnecessary
  horizontal space
- Long tax names (common with OSS) wrapped to multiple lines, making
  the table very tall

**Fix:**
By placing both sub-tables inside a single `<td>` with a flex container,
they can share the available width dynamically based on content rather
than being constrained by arbitrary colspan splits. Removing
`table-layout: fixed` lets columns size naturally to their content.
Using country codes instead of full names and adding ellipsis on long
tax names further reduces the space pressure.

Backport of: ba8099ab7bad7a7a9fe445ed6fda8c4daa7abcbd

opw-5477029

**Steps to reproduce:**
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner or payrun report
- Pay with "Swiss ISO20022" > generate xml pain001
- Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml !

**Cause:**
In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf).

**Solution:**
Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6).

opw-4872507

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Forward-Port-Of: odoo/enterprise#107920

Steps to reproduce:
- Set up a Company with BR localization
- Create a product as follows:
  - [General Information] Product Type: Service
  - [Sales] LC116 Code: 14.01
  - [Sales] Purpose of Use: Not applicable
  - [Sales] Service Code Origin: 14.01.3/168061/1524
  - [Sales] Service Codes: 14.01.3/168061/1524
- Create an Invoice with Document Type "Electronic Service Invoice - NFS-e"
- Add the product on the line
- Compute taxes
- Compute taxes again

Issue:

Action will be blocked by a validation error resulting from the external
taxes call
```
odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice.
Errors: Rejection: Total Installments doesnt match Total Lines
∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0
```

It occurs because during the call the system is considering the
existing taxes on the line and it will send to the avatax service wrong
amounts

opw-5412456
opw-5409735

Forward-Port-Of: odoo/enterprise#108088