Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.

As a result, a partner named "test & test GMBH" was exported as:
  <Nm>test + test GMBH</Nm>
instead of the expected:
  <Nm>test & test GMBH</Nm>

This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.

Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:

- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.

- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.

Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.

ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:

Forward-Port-Of: odoo/enterprise#118897
Forward-Port-Of: odoo/enterprise#115409

Issue
-----
Enabling signature requirement blocks US -> US deliveries.

Steps to reproduce
-----
- Setup UPS
	- enable signature requirement
- Set current company to US
- Create a US Customer
- Create a product with some weight
- Create a SO for the product
- Add UPS delivery and try to get a rate

> Error: "The requested accessory option is unavailable between the selected
locations."

Cause
-----
Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link)

https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US

US50 -> US50 & Canada -> Canada is package level
Everything else is shipment level

By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value.

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911

For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421

-----
Ticket:
opw-6173624

Forward-Port-Of: odoo/enterprise#117564

Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting.

* Introduce dedicated work entry types for:

  * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81)
  * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1)
* Add salary rules and categories for voluntary overtime remuneration.
* Enforce yearly thresholds through payroll parameters:

  * 240h for voluntary overtime exempt from ONSS
  * 120h for voluntary overtime subject to ONSS
* Exclude voluntary overtime from employment bonus calculations and paid amount computation where required.
* Include voluntary overtime remuneration in payroll calculations and DMFA declarations.
* Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields.
* Fix DMFA service hour computation and add payroll/DMFA test coverage.

TaskID: 6275791

Forward-Port-Of: odoo/enterprise#119355

### Description of the issue/feature this PR addresses:

getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days.

So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1.

The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week.

### Current behavior before PR:

At the end of 2026, this will cause problems because the week number will run as:

* 2026, week 52 (all days in 2026, OK)
* 2027, week 53 (most days in 2026, last day in 2027, Not OK)
* 2027, week 1 (all days in 2027, OK)

### Desired behavior after PR is merged:

This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as:

* 2026, week 52 (no changes)
* 2026, week 53 (year is not incremented if week number is not reset)
* 2027, week 1 (no changes, but year is incremented when week number is reset)

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

Forward-Port-Of: odoo/odoo#267871
Forward-Port-Of: odoo/odoo#267656

[FIX] voip: make sure any create/write on voip.call syncs user presence
    
    Commit [1] introduced a "in-call" presence icon. Before this commit,
    code updating call records had to call a specific function if user
    presence potentially had to be changed after the record update. While
    not hacking create/write to do that might be prettier, it is also
    subject to mistakes and one was already made: demo data call record
    creation did not update user presence properly. Commit [2] indeed
    introduced calling/ongoing call demo data and the user presence was not
    correct just after database initialization.
    
    This commit fixes that by now potentially syncing in writes and always
    syncing on create.

[FIX] voip: unstuck user call presence sooner in case of stuck calls
    
    At the moment, the Odoo phone has a freshness system for call records
    that appear still calling/ongoing for a strange duration. Indeed, there
    are still cases where a call ended and we could not detect it. For
    example, the user simply closing the tab where a call is ongoing (we try
    to warn the user before he leaves but if agrees to leave anyway, the
    call is just stopped when connexions are lost but the call record stays
    marked as "ongoing"). In those cases, we have 2 things:
    
    - A once-a-month cron checks all cases that are calling for more than
      5 minutes or ongoing for more than 4 hours. It moves them to "ended
      unexpectedly".
    
    - The displayed status in views, shows "calling" / "ongoing" only if the
      record is not older than 5 min / 4 hours. Otherwise it shows "ended
      unexpectedly" already (as if the cron already did its job), despite
      the record still having the "calling" / "ongoing" status.
    
    It is weird and non-perfect but this allows to not have a "heavy" cron
    job and consistent-enough call records display in views.
    
    Of course, the long-term plan is to have more reliable call records
    status (PBX, ...).
    
    A new problem related to this appeared though. Since [1], a call icon
    is used as the discuss presence icon in case the user is currently on a
    call. The "currently on a call" data being transferred based on a field
    "has_active_call" synchronized on call operations. Problem: in the case
    mentioned above (call stuck in ongoing), that field will stay wrong for
    a full month, showing the user as being on call. This commit makes it
    so the check for active calls now considers fresh-enough calls (just
    like the display in views does). It is only updated on a new call
    operation though, so if an user has a stuck call, he will still be shown
    as being on call until he starts/ends another call (or manually correct
    the stuck call record).
    Again, hopefully, stuck call records will be a thing of the past soon
    enough so that issue will be minimized.
    
    Note: this also uses `effective_start_date` instead of `start_date` to
    check for stale calls, as it handles the potential no start_date while
    ongoing that would stay stuck forever (that should not happen but,
    better safe than sorry).

[FIX] voip: not consider incoming calling calls for presence status
    
    Commit [1] introduced a "in-call" presence status. Commit [2], alongside
    several fixes (e.g. parents of this commit and mentioned commit),
    introduced new call demo data, including calling/ongoing calls:
    - One incoming calling for Mitchell Admin
    - One outgoing calling for Marc Demo
    - One incoming ongoing for Marc Demo
    - One outgoing ongoing for Marc Demo
    
    Consequence: both Mitchell Admin and Marc Demo always have the "in-call"
    presence icon, which might not be the best for demo. Still nice to test
    VoIP but misleading for the rest.
    
    In the end, we can have the best of both worlds: at the moment Mitchell
    Admin only has an incoming calling call... and actually, that kind of
    situation should not lead to being consider as "in-call". Calling
    someone does, but receiving a call that we are potentially ignoring at
    the moment does not.
    This commit makes it so incoming calling calls are not considered for
    presence anymore, at the same time thus making Mitchell Admin presence
    not impacted by default VoIP demo data.
    
[1] - https://github.com/odoo/enterprise/commit/f1e0c41fa7b4f425e45303e5e912bf093c56480a
[2] - https://github.com/odoo/enterprise/commit/f16faa029220ca7152289180c4de78783bab03be
    
task-6239844

Steps to reproduce:
- Ensure you're not in dev mode(`--dev xml` disabled)
- Create ≈200 custom website snippets
- Go into website edit mode
- Traceback appears

Because of the high number of snippets, rendering the snippets templates exceeds the 1024-entry template cache limit. Earlier compiled templates are evicted from the LRU cache and may need to be processed a second time during the same render.

The second compilation reuses the etree stored in the transaction preload cache. As this etree was already consumed by the first compilation, the resulting output can contain empty snippet wrappers and crash the website editor.

This commit always copies preloaded etrees before compilation so the transaction cache retains a clean tree that can safely be processed again after an eviction.
A fix was already done for the same error in [1], where it was only done for dev mode.

opw-6230580
opw-6270833
opw-6276599

[1]: https://github.com/odoo/odoo/commit/f04a5cfee1a5c43824b04dec89712414b79e6cff

Forward-Port-Of: odoo/odoo#268550

Version:
---------
- saas-19.2+

Steps to reproduce:
-------------------

- Install `mrp` and `knowledge`
- Open Knowledge and create an article
- Add a clipboard block and write some text
- Go to Manufacturing → Operations → Manufacturing Orders
- Create a new Manufacturing Order
- Open the `Miscellaneous` tab
- In the `Additional Notes` field, click the Knowledge icon(Top right corner)
- Search and open the created article

Issue:
------
The Knowledge article does not display the
`Use As Additional Notes` action.

Cause:
------

The Knowledge clipboard integration detects compatible editable HTML fields
 from the active form view through `form_controller_patch.js`.

The detection first checks whether the field:
- is part of `KNOWLEDGE_RECORDED_FIELD_NAMES`,
- is an HTML field,
- and is writable.

```
The `note` field already satisfies the first condition: const KNOWLEDGE_RECORDED_FIELD_NAMES = [
    'note',
    'memo',
    'description',
];
```
However, the detection logic also filters out readonly fields:

```py
fields[name].type === "html" &&
!fields[name].readonly
```

In `mrp.production`, the `note` field is computed `Html` field:

```py
note = fields.Html(
    string="Additional Notes",
    compute='_compute_note',
    store=True,
)
```
Since computed fields are readonly by default unless explicitly marked
otherwise, Odoo exposes the field as readonly at the model level.

Even though the form view contains readonly Flase:

https://github.com/odoo/odoo/blob/9b9c72cc2c2ec0f7f5a74b39a11044b5f21f5d2e/addons/mrp/views/mrp_production_views.xml#L583

the Knowledge detection relies on the model field definition rather than
the view attribute. As a result, the `note` field is filtered out and
the clipboard action is never proposed.

 Fix:
-----

Mark the computed `note` field as writable by setting
`readonly=False` in the model definition.

This allows the Knowledge clipboard detection to recognize the field as
a valid editable HTML target and restores the
`Use As Additional Notes` action in Manufacturing Orders.

---

opw-6209675


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

Forward-Port-Of: odoo/odoo#266668