This update improves the Swiss payroll payslip report by incorporating the necessary source tax rate information. This ensures accurate tax calculations and reporting for Swiss businesses using Odoo Enterprise, aligning with local tax regulations.

This commit adds the source tax rate in the payslip report for Swiss payroll.

task-4979330

Forward-Port-Of: odoo/enterprise#112842

This update resolves an issue where uploading fillable PDFs with blank fields resulted in an error. The fix prevents a technical error (IndexError) that occurred when generating PDFs with no data, ensuring that all PDF generation processes now function correctly regardless of form field content.

Version: 19.0

Issue:
- Uploading a fillable PDF with no filled-in values caused an error.

Cause:
- When all form fields are empty, nothing is drawn on the ReportLab overlay canvas, producing a 0-page PDF.
- Calling getPage(0) on an empty page list raised an IndexError.

Fix:
- Skip the page merge when the overlay has no pages to avoid the IndexError on empty fillable forms.

This update fixes an issue where the activity rate used for payroll calculations was incorrectly tied to individual employees instead of the Odoo Enterprise version. This ensures consistent and accurate payroll processing across all users of the system, aligning with the correct version-based configuration. The change improves payroll accuracy and reduces potential discrepancies.

…ployee

Forward-Port-Of: odoo/enterprise#119658

This update fixes an issue where credit limit warnings were incorrectly triggered when customers received bank payments. The system now accurately considers outstanding bank payments in its calculations, ensuring warnings only appear when the credit limit is genuinely exceeded. This improves the accuracy of credit risk management.

Before this fix:
The credit limit warning calculation only considered credit notes but ignored outstanding bank payments 
when computing the partner's effective outstanding balance. For example, if a customer had a credit limit
of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning 
would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the
actual outstanding amount was only 500.

After this fix:
The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases 
are handled:
- Bank payments received but not yet matched to any invoice, these are identified by their open suspense
  account entry and deducted from the partner's outstanding exposure.
- Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable
  line and deducted accordingly.

So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500
and does not show a warning since it is within the 1,000 credit limit.

task-5427613

Forward-Port-Of: odoo/enterprise#119691
Forward-Port-Of: odoo/enterprise#118957

This update resolves an issue where the commission report displayed empty groups when linked to inactive commission plans. By excluding these plans from the report's initial data processing, the report now accurately shows populated groups, providing a cleaner and more reliable view of commission achievements. This ensures sales teams have accurate data for their performance analysis.

Steps to reproduce:

1. create a commission plan
2. invoice an SO with the linked salesperson to the plan to progress towards the target
3. Archive the commission plan
4. Go to Sales > Commissions > Commissions
5. Remove all filters

The `sale.commission.report` includes empty groups for `sale.commission.achievement.report` that are linked to inactive commission plans

By excluding said plans from the initial join, the report would display populated groups only without the clutter.

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

Forward-Port-Of: odoo/enterprise#119695
Forward-Port-Of: odoo/enterprise#117615

This update resolves a crash in the payslip PDF report that occurred when employees didn't have a bank account configured. The fix adds a conditional check to the report template, preventing it from attempting to access bank account information when it's not applicable. This ensures the report consistently generates without errors.

The payslip PDF report crashed when the employee had no bank account configured because the template tried to access bank_account_ids[0] unconditionally.

Add a t-if guard on the bank account div to only render it when the employee has at least one bank account linked.

This update ensures that DATEV customer and supplier export files accurately reflect customer information. Previously, non-EU customers (like those in Switzerland) incorrectly included EU-specific fields. Now, the system correctly uses the customer's country code in the 'Land' field, aligning with DATEV's requirements and improving data accuracy for reporting.

### Issue:
In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled

However, these fields must only be used for EU countries

For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors

### Cause:
`_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries

As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU

Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create a customer in Switzerland with a valid VAT number
- Create and confirm an invoice for that customer
- Go to Accounting → Audit Reports → General Ledger
- Select the full year
- From the gear menu, export DATEV DATA (zip)
- Open the `EXTF_customer_accounts` file

### Before the fix:
`EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty

### After the fix:
`EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled

`Land` is filled using the following priority:
1. Partner country_code
2. Country extracted from the VAT number
3. Empty

opw-5902565

Forward-Port-Of: odoo/enterprise#119593
Forward-Port-Of: odoo/enterprise#113835

This update resolves a minor issue where the displayed name for the Sendcloud website delivery module had a typo ("Sendcould"). All other references within the system use the correct spelling. This ensures consistent and accurate module identification.

The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.

opw-6239003

Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#118223

This update optimizes the performance of account reports when hovering over tables with many columns. Previously, hovering caused significant lag and browser slowdowns. This change reduces the number of style calculations, resulting in a smoother and faster user experience.

This update streamlines spreadsheet document handling by disabling versioning for spreadsheets and frozen spreadsheets. This prevents unnecessary data duplication and improves performance, aligning with how spreadsheets manage their history through revisions. The change also hides the versioning action for these document types.

This PR consists of two commits.

The first commit hides the Manage Versions action button for spreadsheet and
frozen spreadsheet documents, since versioning is disabled for those
records.

The second commit is a backport of enterprise commit 0e319d0.
It disables document versioning for spreadsheet and frozen spreadsheet
documents, as spreadsheets already manage their history through
spreadsheet revisions.

This avoids creating unnecessary document history attachments when
spreadsheet data is written or when a spreadsheet is copied.

Task: [6236496](https://www.odoo.com/odoo/project/2328/tasks/6236496)

Forward-Port-Of: odoo/enterprise#119619
Forward-Port-Of: odoo/enterprise#118484

This update corrects a display issue related to Sunday formatting in the Thai (th_TH) locale, which was impacted by a recent Chrome browser update. The change ensures consistent and accurate date display across different Chrome versions, maintaining a positive user experience for Thai-speaking customers.

Chrome 148 changed the display format for Sundays in the th_TH locale.

This commit modifies the test to expect either the full or abbreviated day name, depending on what the browser Intl API actually returns.

Forward-Port-Of: odoo/enterprise#119708

This update prevents empty ICS calendar files from being generated when scheduling shifts. Previously, clicking 'Add to Calendar' resulted in an unusable file. The fix ensures ICS files are only created when a valid shift slot is linked to a resource, improving the scheduling process.

**Step:**
- install planning
- create a resource
- create an open shift for a future date
- in Gantt view:
  - publish shift and select the created resource
  - click “Publish & Send”
- check the email and click “Add to Calendar”

**Issue:**
Currently, clicking “Add to Calendar” generates an empty ics file.

**Reason:**
During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file.

**Fix:**
Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file.

Forward-Port-Of: odoo/enterprise#118978