This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the codebase. The most significant changes focus on ensuring that document folio numbers are correctly managed in accordance with available CAFs, making the certificate model more robust, and updating code style for clarity and consistency.

This improvement is mostly made because CAFs have expiration dates and fixed folio numbers. If the expiration date is reached but the folios were not fully consumed, the system will try to generate a document with following number in the sequence but an error will be raised because that number belongs to an expired CAF, althought the user had already uploaded a new CAF.
To fix this, whenever the system looks for the highest number to set to a document, it previously check if that number is between the folio numbers of a valid CAF file.

### Chilean electronic document sequence management

* Added `_get_last_sequence` method to `account_move.py` to ensure that the folio number used for Chilean electronic documents (DTE) is valid and corresponds to an available CAF. If no CAF is available for the current folio, the sequence is reset using the document type's prefix and starting number.

### Certificate model validation

* Made `subject_serial_number` a required field in the `Certificate` model, enforcing that every certificate has a valid owner document and improving data integrity. We made this change to prevent the field being empty after loading the certificate in Odoo, since it is required by the SII to validate invoices.

This improvement enhances user control over cookie preferences by making
the Cookie Policy page (/cookie-policy) more accessible and allowing
users to modify their consent at any time.

**Issue:**

- Previously, the only way to access the Cookie Policy page was through
  the link in the cookie consent popup. However, once users accepted
  cookies, the popup was no longer displayed, making it impossible to
  navigate to the policy page later.

- Additionally, the Cookie Policy page had a button to reopen the cookie
  consent popup, but it was only visible if cookies were not accepted.
  Once cookies were accepted, the button was hidden, preventing users
  from changing their preferences.

**Improvements:**

- Added a permanent link to the Cookie Policy page in the copyright
  footer, ensuring it remains accessible at all times.

- The cookie consent toggle button now remains visible even after a user
  has accepted cookies, allowing them to update their preferences at any
  time.

task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416)

Forward-Port-Of: odoo/odoo#203409

Steps to reproduce:
1. Go to Rental module > Configuration > Enable Rental Transfer
2. Create a product and Update quantity by assigning "By Unique Serial Number"
3. Create a rental order
4. Unhide the "Reserved Lot" field, select the lot created earlier, and confirm
5. Open the Delivery(Stat button), assign lots to both deliveries
6. Create a second rental order (same or different user), assign the same lot, confirm, and process delivery
7. Create a third rental order, enter the same reserved lot → traceback occurs

Issue:
- Traceback with error `ValueError: Expected singleton: stock.move(88, 90)`.

Cause:
- The compute method `_compute_available_reserved_lots` accessed `move_id.date_deadline` directly, assuming a singleton. When multiple stock moves existed for the same lot, it triggered a singleton error.
- When the same lot is linked to more than one delivery, the system crashed when checking available reserved lot.

Solution:
- Handled multiple stock.move.line records per lot by iterating over them instead of assuming a singleton.
- Replaced direct access to move_id.date_deadline with an any() check to safely evaluate deadlines.
- This prevents singleton errors when the same lot is linked to multiple deliveries and ensures correct availability calculation.
 
opw-4963263

Forward-Port-Of: odoo/enterprise#94299

## Issue:
When you use the Smart button `Quality Checks` on a `stock.move` to validate QC, marking a test as Fail doesn't move the `stock.move` to the failing location even if the QC is now failed
This affects all quantity-based checks (Measure or Pass/Fail)

## Cause:
The `do_fail()` method marks the check as failed but does not call `_move_line_to_failure_location()`, so the move line stays in the original location

## Fix:
Trigger the failure wizard when failing a QC via the buttons
This allows the user to confirm the failure and select the appropriate failing location if multiple are configured

## Steps to reproduce:
- Enable Storage Locations in Settings
- Create a Product and a Quality Point (Product: Quality, Operations: Receipt, Control per: Quantity, Type: Measure, Tolerance: 0.0 to 1.0, Failure Locations: WH/Failure)
- Create a New Receipt for the Product and Mark as Todo
- Open 'Quality Checks' via the Smart button, select the QC, enter a measure value above the tolerance (e.g., 2.0), and click Measure.
- The QC should be marked as failed
- Before the fix, the details of the line in the Receipt doesn't change to the failing location
You can also do the same flow with a QP of type Pass/Fail and the Fail button

opw-4920391

Description of the issue/feature this PR addresses:

After a refactor, the month view no longer displayed homeworking locations as in previous versions. This PR fixes the issue and adapts the component using the updated version of the FullCalendar library.

Also fixes a small issue of when different locations with same icons are grouped together when they shouldn't

Current behavior before PR:

All days in the calendar month view displayed the 'Set location' button, regardless of whether a location record existed for the day or not.

Locations of a different type sharing the same icon (Office, Building 1...):

<img width="262" height="135" alt="before" src="https://github.com/user-attachments/assets/51745152-5f90-4917-9627-07aa0959eb3d" />

Desired behavior after PR is merged:

Locations are shown in the month view, and can be interacted with in the same way as in the week/day views, both for single and multicalendar:

<img width="1230" height="504" alt="multicalendar" src="https://github.com/user-attachments/assets/34108f57-2c25-400e-9fbe-106e2233c677" />

<img width="1232" height="382" alt="singlecalendar" src="https://github.com/user-attachments/assets/f4a0cf32-636f-49ce-a4cc-e53a9ac45643" />

Locations of a different type sharing the same icon:

<img width="256" height="132" alt="after" src="https://github.com/user-attachments/assets/643dd304-aeeb-48ec-abef-755e3eb5fdf0" />

---
Task ID: 5215931

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade, those strings will be translated in different languages and will trigger an error[^1] when they cannot be accessed in the dict. This can also fail during a local upgrade, not necesarily during an upgrade in the platform.

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
    self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Akun'
```

[^1]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L423
[^2]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L393-L397

Forward-Port-Of: odoo/odoo#238368

## Versions
18.0 to saas-18.3
Fixed by 7b56a6afda919f3c09d08eb1256416e0a2b4b1d9 introducing a new logic with https://github.com/odoo/odoo/blob/26f9cab34a8cd594192d9e2a844494196b9ca5b6/addons/sale/controllers/product_configurator.py#L329

## Issue
Duplicating an attribute on a product leads to a traceback when adding the product to a SO.

## Steps to reproduce
*Ensure variants are activated in the settings*
- Create a new test product:
  - Attributes & Variants (on 2 distinct lines):
    - "Brand": 1;
    - "Brand": 2 & 3.
- Create a new SO:
  - Add the test product.

## Cause
The product has 2 attribute lines referring to the same attribute. As both attribute lines point to the same attribute, `ptals.attribute_id.read()` returns only one value for two ptals. The `zip()` call therefore drops the extra ptal, producing an incomplete mapping. When the configurator later tries to access this missing ptal entry, it crashes https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/sale/controllers/product_configurator.py#L321.

opw-5373672

When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled):
- the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version,
- the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version.

Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ...

In the future we would like to handle the received services(formats) on IAP directly to handle change better.

https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50

I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion.

<img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" />

Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json