An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]).

This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues.

The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them.

This reverts the whole accent sanitization saga:

- Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4.

This also removes the unused frozendict import to make "Check Style" happy.

opw-5915515

[1] https://github.com/odoo/enterprise/pull/95207
[2] https://github.com/odoo/enterprise/pull/107960
[3] https://github.com/odoo/enterprise/pull/96043
[4] https://github.com/odoo/enterprise/pull/106557
[5] https://github.com/odoo/enterprise/pull/107677

Closes odoo/enterprise#107960

Forward-Port-Of: odoo/enterprise#108189

## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.

## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].

## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.

runbot-241028

Forward-Port-Of: odoo/enterprise#108333

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Forward-Port-Of: odoo/enterprise#107920

**Steps to reproduce:**
- Install l10n_ro_saft
- Switch to a Romanian company (e.g. RO Company)

- Create an asset model:
  * Method: Straight Line
  * Duration: 12 Months
- Configure a "Fixed Assets" account:
  * Automate Asset: Create and validate
  * Asset Model: [the asset model created above]
- Create a bill:
  * Vendor: [create a new vendor]
  * Bill Date: [last month]
  * Invoice Line: [A line with the fixed asset account]
- Confirm the bill

- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Select the current month (The fixed asset account should be present)
- In the cog menu, select "SAF-T (D406 Asset Declaration)"

**Issue:**
A traceback is raised while trying to display the name of a supplier.

**Cause:**
To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report.
In this case, it's the current month.
However, the created bill has been posted the month before.
So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict.

**Solution:**
Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft.


opw-5499918

Forward-Port-Of: odoo/enterprise#105987

Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear

<details><summary>Exact Traceback</summary>
<p>

```
RPC_ERROR

Odoo Server Error

Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
    return retrying(serve_func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
    return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
    return report_method(model, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
    self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
    self._get_vat(),
    ^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
    if vat.startswith(('GB', 'XI')):
       ^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
        at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```

</p>
</details> 

Reason:
- No VAT set on the current company.

Solution:
- Blocking level error for the user to set VAT on the current company.

Task-5929908

Forward-Port-Of: odoo/enterprise#107150

## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
    - *Subscriptions* checked
    - *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
    - Any Customer
    - Any plan
    - Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**

## Causes

In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":

https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62

This is the case of upsells, as explained here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

---

Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.

https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78

In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.

| Upsell | Invoiced based on delivered quantities | last_invoiced_date      |
|--------|----------------------------------------|-------------------------|
| True   | True                                   | today + 1 month         |
| False  | True                                   | today                   |
| True   | False                                  | today + 1 month - 1 day |
| False  | False                                  | today + 1 month - 1 day |

An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.

---

opw-5500585

Forward-Port-Of: odoo/enterprise#107967