Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106

Forward-Port-Of: odoo/enterprise#106146

Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company and create a new employee.
3. Create a new internal user with Payroll Officer/Manager access.
4. Log in as that user, create a contract, and click on "One-time payments".

Issue:
---------
A Traceback with AccessError:
```You are not allowed to access 'Action Window' (ir.actions.act_window) records.```

Cause:
----------
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195
The code attempts to call `.read()` on an `ir.actions.act_window` record.
Standard users typically do not have read access to window action records,
resulting in an **AccessError** even if they have rights to the payroll data.

Solution:
-------------
Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id
in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction.

opw-5491467

Forward-Port-Of: odoo/enterprise#106598

Steps to produce:
---
- Install `accountant` and `l10n_mx` modules.
- Switch to Mexican company.
- In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`.
- Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice.
- Mark the invoice as global.
- Register the payment.
- Create a credit note and confirm it.
- Click Send(make sure CFDI is checked) and check the generated XML.

Issue:
---
- The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`.

Solution:
---
- Preserve the original line description for CFDI refunds instead of forcing
  the generic label.
- For POS refunds, continue using the generic label.
- This aligns with the fix introduced in 19.0([here]).

Before:
---
<img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" />

After:
---
<img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" />



[here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436
**Backport of https://github.com/odoo/enterprise/pull/97681**

opw-5870052
---

Forward-Port-Of: odoo/enterprise#107367

Steps to reproduce:
1. Install `website_knowledge`
2. Create a long, scrollable knowledge article with 20 sub-articles.
3. Share the article publicly
4. Open the public link in mobile view (logged out)
5. Toggle the sidebar using the top-left menu button
6. Scroll down

Issue:
- On mobile, the public sidebar overlaps with the article's content while scrolling.

Cause:
- the sidebar and its backdrop were positioned absolutely inside a flex container. Because they were not fixed to the viewport, the article content continued to scroll and render underneath the sidebar, causing visible overlap between the sidebar and the article body. Additionally, the sidebar’s internal scroll container was not explicitly positioned, which contributed to inconsistent scrolling behavior when the sidebar was open.

Solution:
- Update the public Knowledge sidebar css to behave as a proper mobile overlay by: Fixing the sidebar and its backdrop to the viewport using position: fixed, ensuring they are removed from the flex layout flow on mobile Explicitly positioning the sidebar’s internal scroll view to ensure correct scrolling behavior

<table>
  <tr>
    <td><strong>Before</strong></td>
    <td><strong>After</strong></td>
  </tr>
  <tr>
    <td><img width="725" height="901" alt="Before image" src="https://github.com/user-attachments/assets/33190684-5b52-4931-b01a-5044734c9cf0" /></td>
    <td><img width="686" height="916" alt="After image" src="https://github.com/user-attachments/assets/610a5aef-3467-4215-a0a0-83607375a016" /></td>
  </tr>
</table>


opw-5384026

Forward-Port-Of: odoo/enterprise#103135

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

[opw-5915515](https://www.odoo.com/odoo/project.task/5915515)

Forward-Port-Of: odoo/enterprise#107677

Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

Forward-Port-Of: odoo/enterprise#106392