This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML adheres to current Swiss banking standards, improving payment processing accuracy and compliance. It also includes enhancements for validator schema and QR-IBAN support.

**PROBLEM**
According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured.
This isn't the case when generating a xml for the payment method iso20022_ch.

**STEP TO REPRODUCE**
1. install l10n_ch and account_iso20022.
2. Create a swiss contact with a full address. And activate payment on the bank account of this contact.
3. Select the Company CH, and set a bank account in the bank journal configuration.
4. Create a vendor payment to the swiss contact.
5. Create a batch payment with it, and validate to get the xml.
6. Open the xml, and notice the PstlAdr isn't structured.

Ticket [link](https://www.odoo.com/odoo/project.task/5880247)
opw-5880247

Forward-Port-Of: odoo/enterprise#107025

This update automatically calculates and transmits the required commission payments (ELM) for Swiss payroll, streamlining the process for our Swiss clients. The change ensures accurate reporting to Swiss tax authorities, reducing the risk of errors and improving compliance. This update impacts the Swiss payroll module.

Forward-Port-Of: odoo/enterprise#111143

This update fixes an issue where repositioning PDF signs within the Odoo interface caused erratic resizing behavior due to multiple event listeners. The change ensures only one resize listener is attached per sign, resulting in a more reliable and predictable resizing experience for users. This enhances the overall usability of the PDF sign functionality.

Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior.

This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction.

task-6048759

Forward-Port-Of: odoo/enterprise#111146

This update fixes an issue in how tax reports calculate period boundaries, particularly when using 'trimester' tax periods. The change ensures accurate reporting by correctly identifying the relevant tax period for calculations, preventing incorrect values being displayed in reports. This improves the reliability of financial reporting.

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111330
Forward-Port-Of: odoo/enterprise#110504