**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#123267

**PROBLEM**
`_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic.

**STEP TO REPRODUCE**
1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration.
2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
  - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id),
  - has res_field = NULL (record attachment, not a field binary),
  - is posted to the chatter → it has a row in message_attachment_rel.
3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size.
4. Run the cron _cron_migrate_local_to_cloud_storage.
5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping).

**FIX**
Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()`

opw-6347198

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#271829

### Description of the issue/feature this PR addresses:
This PR fixes an issue in the `resource` module where flexible working hours cause unpredictable and shifting non-working (greyed-out) days on the Timesheets and Calendar views. It restores the weekly Monday anchor for flexible hour calculations while safely preserving a prior fix for partial-day work entries on public holidays.

### Current behavior before PR:
In `_attendance_intervals_batch`, the calculation for flexible schedules sets `current_start_day = start_date`. Because `start_date` is often passed as the first day of the month or a requested period (which can fall on any day of the week), the 7-day calculation cycle becomes unanchored. Odoo blindly allocates 8 hours to the first 5 days of this arbitrary period and leaves the 6th and 7th days empty. This results in the visual "weekend" shifting randomly month-to-month (e.g., greying out Wednesdays and Thursdays instead of Saturdays and Sundays).

### Desired behavior after PR is merged:
The `current_start_day` is correctly anchored back to Monday using `start_date - timedelta(days=start_date.weekday())`. This ensures the 5-day allocation always consistently spans Monday through Friday, keeping Saturday and Sunday as the standard non-working days on the UI grids. Furthermore, because the `min()` clamp on `remaining_hours` is retained, partial-day Work Entry generation (like a 2-hour gap on a Wednesday public holiday) continues to calculate correctly without attempting to over-allocate the remaining weekly hours.

opw-6370301

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

# How to reproduce
- Set an employee's work schedule to flexible 40hrs/week with 8hrs of work per day
- Create a new attendance for that employee that :
	- Is the very first attendance of that employee
	- Is not on a monday (e.g. a Friday)
- Create a second attendance for that employee that :
	- Is atleast one week after the first attendance
	- Is one of the two days of the week before the day of the week of the first attendance (e.g. a Wednesday or a Thursday)
- Go to the settings, update the value for "Tolerance Time In Favor Of Company" and save
- Come back to the second attendance

# The problem
The Extra Hours have changed and are equal to the worked time

# Cause
When we update the tolerance time, we recompute the overtime of every attendance of every employee.
In this recomputation, we compute the `expected_attendance` of every employee and transforms
them into a dict of the expected working time for each day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L349-L356

Later, if an attendace of the employee was not in their expected working days, then we consider that all hours worked were overtime :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L381-L384

This makes sense but our issue is that days in the middle of the week are considered "time-off" when they
should not. That's because for flexible working schedules, we emulate the expected working hours based on
the total hours per week and the maximum hours per day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/resource/models/resource_calendar.py#L384-L386

For every "week", we start from the first day and continue forward by greedily using all hours for that
day until there is no more hours for the week. The problem is that since this PR, we don't start "weeks" on
mondays, but on the `start_datime` :
https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

And in our case, `start_datetime` is the very first attendance day of the employee :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L344

So our expected working days are desynched with the days of the week

# Proposed solution
We partly revert https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

opw-6289079