Version-19.0

**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
                We need that information at other places too.
                
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
        1. A new contract is created
        2. an existing version changes it start date, or 
        3. an existing version is deleted for the employee.

### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
  `contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
       1. fetches all the active versions of employee
       2. filter those having `contract_date_start`
       3. Computes the earliest start date.
       4. Updates `employee.first_contract_in_company` accordingly.

**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.

Forward-Port-Of: odoo/enterprise#107971
Forward-Port-Of: odoo/enterprise#102198

Step to Reproduce:
* Install l10n_my_edi_pos and switch to that company
* Configure two POS sessions (POS 1 and POS 2)
* Create orders as follows:

POS 1:
* 2 uninvoiced orders
* 1 invoiced order
* Close POS 1

POS 2:
* 1 uninvoiced order
* 1 invoiced order
* Close POS 2

Reopen POS 1:
* 1 uninvoiced order
* Close POS 1

Reopen POS 2:
* 1 uninvoiced order

Close POS 2
* Go to Orders → Consolidated Invoice
* Create a consolidated invoice using the correct date range

Observation:
* Two documents are created
* No. of orders linked to each document are incorrect

Cause:
* `_split_pos_orders_in_lines` overwrites entries in the `lines_per_config` dictionary
* Previous orders for the same config are lost

Fix:
* Extend the existing recordset in `lines_per_config`  instead of overwriting it

Before
<img width="1230" height="231" alt="order consolidation bug" src="https://github.com/user-attachments/assets/26657f34-998e-41c4-a68a-0939cbe6de1d" />

After
<img width="1265" height="206" alt="consolidated order fixed" src="https://github.com/user-attachments/assets/7c703416-ac3b-412e-bb28-0d6f73fa25f2" />


opw-5904420

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

Forward-Port-Of: odoo/odoo#248402

In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior.

The dashboard query for payments to check was executed with the default `bypass_access=False`, causing record rules to be applied. This introduced extra joins (e.g. on `res_company`) and resulted in ambiguous column errors during aggregation.

```py
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 414, in _get_journal_dashboard_data_batched
    self._fill_sale_purchase_dashboard_data(dashboard_data)
   File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 600, in _fill_sale_purchase_dashboard_data
    self.env.cr.execute(sql)
   File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
    self._obj.execute(query, params)
 psycopg2.errors.AmbiguousColumn: column reference "currency_id" is ambiguous
LINE 1: SELECT journal_id, company_id, currency_id AS currency, invo...
                                       ^
```

Set `bypass_access=True` to match the original `_where_calc` behavior and avoid unnecessary joins.

opw-5951694
upg-3902613

[^1]: https://github.com/odoo/odoo/commit/6f95152b00df75f503f445e3b77b891b5f83c055





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

Forward-Port-Of: odoo/odoo#250003

Steps to produce:
---
- Install `sale_renting` and `sale_management` modules.
- Go to `Sales > Products > Products`.
- Create a product and disable the Sales option (`sale_ok = False`).
- Create a Sales Order and try to add that product.

Issue:
--
- Even though the product is not sale-enabled (`sale_ok = False`), it is still selectable in the Sales Order.

Root cause:
---
- At [1], The issue occurs because `super_domain` was not always included.
- When `order_is_rental` is True, `super_domain + []` happens,
  so only `super_domain` is applied.
- But when `order_is_rental` is False, instead of
  `super_domain + [('rent_periodicity', '=', False)]`, only
  `[('rent_periodicity', '=', False)]` was returned, and
  `super_domain` was ignored.
- Because of this, base conditions from `super_domain` like
  `sale_ok = True` were not applied.

Solution:
---
- Add parentheses around the conditional expression to ensure proper evaluation order and correct domain construction, so only products with `sale_ok = True` are selectable.

[1] https://github.com/odoo/enterprise/blob/abfde5f253c4c52d3a734ca8dafe6f8ed261cf75/sale_renting/models/sale_order_line.py#L49

opw-5902403
---

Forward-Port-Of: odoo/enterprise#107639

Steps to reproduce the issue:
1. Install the module `l10n_mx_hr_payroll_account_edi`.
2. Generate a payslip for an employee.
3. The following traceback is raised at the moment to click on "Generate CFDI" button: 
```py
File "/data/build/odoo/odoo/addons/base/models/ir_qweb.py", line 858, in _render_iterall raise 
QWebError(qweb_error_info) from error odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the 
template: KeyError: 'l10n_mx_ssn' Template: l10n_mx_hr_payroll_account_edi.report_payslip_mx_cfdi Reference: 
8166 Path: /t/t/div/t[2]/div[4]/table[2]/tbody/tr/td/div[5]/span[1]
    Element: <span class="ms-1" t-field="o.version_id.l10n_mx_ssn"/>
```

---
To avoid moving the `l10n_mx_ssn` field from the `hr.employee` model to `hr.version`, the `t-field` in the template is updated to `o.employee_id.l10n_mx_ssn`.

This approach is valid because an employee's SSN rarely changes. If a modification is ever needed, it can be updated directly on the employee form, where the field is already tracked.

target: saas-19.2
task-5962423

Description
-----------
Getting an `hr.version` from an `offer` during simulation is done in
a savepoint, preceded and followed with flushing of the environment
and some post-cleanup. This is verbose and error-prone, as it's done
at each call site of `hr.contract.salary.offer._get_version` and
`hr.version._generate_salary_simulation_payslip` (or any other
future method that may require such a savepoint). These methods have a
comment that mentions *requiring* a savepoint to be called, but
nothing is enforcing it, so a bug due to oversight is bound to
happen. Context keys are also injected a bit everywhere like
`salary_simulation` and `tracking_disable`, without much consistency,
and adding to the visual clutter.

This commit introduces a little context manager called
`hr_version_context` that manages the creation of the savepoint, the
setup and teardown necessary, and the setting of the keys in the
context.
It's accompanied by a decorator `@requires_hr_version_context` that
will fail if the caller didn't use `hr_version_context` before
invoking the marked method.

This ensures:

- Correct creation of the savepoint and its related pre-/post-operations
- Apply context keys consistently
- Ensure methods that require such setup *cannot* be called without it.

Forward-Port-Of: odoo/enterprise#107743
Forward-Port-Of: odoo/enterprise#103187

With an `l10n_it` company:
- Create an invoice in a foreign currency and export the XML.

In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency.
`ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document:
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b

> L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che
> “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”.
> Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>`
> deve essere obbligatoriamente “EUR”.

> Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that
> “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.”
> Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>`
> field must mandatorily be “EUR”.

As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field
(assuming the company currency is always EUR for `l10n_it`).

Ticket [link](https://www.odoo.com/odoo/project.task/5913088)
opw-5913088

Forward-Port-Of: odoo/odoo#249272
Forward-Port-Of: odoo/odoo#247537

Step to Reproduce:
* Install l10n_my_edi_pos and switch to that company
* Configure two POS sessions (POS 1 and POS 2)
* Create orders as follows:

POS 1:
* 2 uninvoiced orders
* 1 invoiced order
* Close POS 1

POS 2:
* 1 uninvoiced order
* 1 invoiced order
* Close POS 2

Reopen POS 1:
* 1 uninvoiced order
* Close POS 1

Reopen POS 2:
* 1 uninvoiced order

Close POS 2
* Go to Orders → Consolidated Invoice
* Create a consolidated invoice using the correct date range

Observation:
* Two documents are created
* No. of orders linked to each document are incorrect

Cause:
* `_split_pos_orders_in_lines` overwrites entries in the `lines_per_config` dictionary
* Previous orders for the same config are lost

Fix:
* Extend the existing recordset in `lines_per_config`  instead of overwriting it

Before
<img width="1230" height="231" alt="order consolidation bug" src="https://github.com/user-attachments/assets/26657f34-998e-41c4-a68a-0939cbe6de1d" />

After
<img width="1265" height="206" alt="consolidated order fixed" src="https://github.com/user-attachments/assets/7c703416-ac3b-412e-bb28-0d6f73fa25f2" />


opw-5904420

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

Forward-Port-Of: odoo/odoo#248402

Currently, modifying a loaded order (e.g., changing product quantity) does not save the changes, and the old order without modifications is shown on the ticket screen.

### **Steps to Reproduce:**
1) Install the POS Restaurant app with demo data.
2) Open a Restaurant Session.
3) Click on 'Register' to create a Direct Sale.
4) Add a product (e.g., Water with Qty 2) and a customer (e.g., 'Billy Fox'). 
5) Click on 'Orders' from the navbar and load the recently created order. 
6) Update the quantity of Water from 2 to 5 and click on 'Orders' again.

### **Error:**
The quantity of Water is not updated, the order line still shows a quantity of 2.

Ref video: https://drive.google.com/file/d/1XR5W5Klyyll3KujirKb3UuAELjMcA7yD/view

### **Root Cause:**
Clicking on 'Orders' calls `syncAllOrders` (see [1]), which is responsible for updating the orders. However, `this.getPendingOrder()` returns null in this scenario, causing the orders array to be empty and the function to return early without syncing.

### **Fix:**
Override `updateSelectedOrderline` in `OrderSummary`. This method is
invoked whenever the Numpad modifies an orderline. By calling
`addPendingOrder` within this method, we ensure that Numpad modifications
are correctly registered. This allows `syncAllOrders` to properly sync
the updated order with the server when navigating away.

[1]- https://github.com/odoo/odoo/blob/7fd5f90fe8fce4de49ec10c683f92e7a3557981a/addons/point_of_sale/static/src/app/services/pos_store.js#L1485-L1512

opw-5405402

Forward-Port-Of: odoo/odoo#240366

In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior.

The dashboard query for payments to check was executed with the default `bypass_access=False`, causing record rules to be applied. This introduced extra joins (e.g. on `res_company`) and resulted in ambiguous column errors during aggregation.

```py
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 414, in _get_journal_dashboard_data_batched
    self._fill_sale_purchase_dashboard_data(dashboard_data)
   File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 600, in _fill_sale_purchase_dashboard_data
    self.env.cr.execute(sql)
   File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
    self._obj.execute(query, params)
 psycopg2.errors.AmbiguousColumn: column reference "currency_id" is ambiguous
LINE 1: SELECT journal_id, company_id, currency_id AS currency, invo...
                                       ^
```

Set `bypass_access=True` to match the original `_where_calc` behavior and avoid unnecessary joins.

opw-5951694
upg-3902613

[^1]: https://github.com/odoo/odoo/commit/6f95152b00df75f503f445e3b77b891b5f83c055





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

Forward-Port-Of: odoo/odoo#250003

## Short functional explanation of the error
When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B.

## Reproduction Steps
1. Create a second company to your database. Let's call these companies Company A and Company B.
2. Select Company A as your main company, but make sure Company B is also selected.
3. Create an Employee A.
4. Select Company B as tour main company; but make sure Company A is also selected.
5. Create an Employee B who has A as manager.
6. Create Employee C who has B as manager.
7. With a user only having access to Company B, log in and try to access Employee C's page.

### Expected behavior
Employee's C page loads correctly.

### Unexpected behavior
An access error occurs.

## Origin of the issue
A sudo() was missing.
__
opw-5910036





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

Forward-Port-Of: odoo/odoo#247817

Enterprise PR: https://github.com/odoo/enterprise/pull/108109

The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as letting us query the status of the printer to check if it was e.g. out of paper.

However, using this library has complicated the code and caused many reliability problems when using USB printers. In particular, the printer could print garbage and then become stuck until it was restarted. This seems to be due to a multi-threading issue, as the print is interrupted half-way through when the `USBInterface` checks for devices.

Since the added value is small compared to the extra maintenance and reliability costs, the `python-escpos` library is being removed in favour just using CUPS for all print jobs, as was the case in 18.0. This means we will no longer have a QR code on the status receipt or a warning when the paper is running low, but these are unimportant compared to reliability.

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

Forward-Port-Of: odoo/odoo#249819

When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate.

Steps to reproduce the error:
- Install ``l10n_it_edi`` module with demo data
- Switch to IT Company
- Create a new invoice > Customer: IT Company > Add a product > Confirm >
  Send > Send
- Actions > Print > XML FatturaPA

Traceback:
```py
TypeError: string indices must be integers, not 'str'
```

In commit [1], ``_get_invoice_legal_documents`` was updated to return a list instead of a dictionary.
However, the ``l10n_it_edi`` module was not adapted accordingly and still returns a dictionary at [2].
If ``_get_invoice_legal_documents`` returns a dictionary instead of a list,
the following logic incorrectly iterates over dictionary key which leads to the above traceback.
https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/account/controllers/download_docs.py#L24-L26

[1]: https://github.com/odoo/odoo/commit/90dcd6cfe904974dfa077c2d8d9e168a09eeecf9
[2]: https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/l10n_it_edi/models/account_move.py#L399-L403

sentry-7272542156

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

…r rejections

Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors.

The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use.

This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ...

The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading.


See-also: #243119

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Steps to reproduce
-----
- Enable locations & by products
- Create 4 locations
	- View A of type view (parent: Stock)
	- View B of type view (parent: Stock)
	- Storage A of type internal location (parent: View A)
	- Storage B of type internal location (parent: View B)
- Create a "Manufacture to A" route
	- Rule 1: Manufacture, Stock -> Stock
	- Rule 2: Push To, Internal Transfer, Stock -> View A
- Create a "By Products to B" route
	- Rule 1: Push To, Internal Transfer, Stock -> View B
- Create a "Bonus" product with route "By Products to B"
- Create a "Finished" product with route "Manufacture to A"
	- BoM with "Bonus" as by product
- Create a MO for Finished, and produce it
- Open the linked transfers' list view
- Open the "Bonus" transfer

> "Destination Location" states View B

- Open the line's details (hamburger button)

> "Store To" states View A/Storage A

Cause
-----
When retrieving the location in

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282

we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260

This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371

which might not be a child of the location.

Solution
-----
By removing the context key, locations get populated as such

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330

This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location.

-----
Ticket:
opw-5359945

Forward-Port-Of: odoo/odoo#249708
Forward-Port-Of: odoo/odoo#247403

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty the Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record
  is not a field service task.
* Field service tasks should always keep the sale order linked so materials can
  still be added to the existing sale order, even when the task is non-billable
  (i.e., no sale order line is linked). This logic is handled by the compute
  override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935
[2]:
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487

opw-5215989

Forward-Port-Of: odoo/odoo#249574
Forward-Port-Of: odoo/odoo#241446

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

Forward-Port-Of: odoo/enterprise#107990
Forward-Port-Of: odoo/enterprise#103487

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#104686
Forward-Port-Of: odoo/enterprise#103333

With an `l10n_it` company:
- Create an invoice in a foreign currency and export the XML.

In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency.
`ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document:
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b

> L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che
> “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”.
> Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>`
> deve essere obbligatoriamente “EUR”.

> Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that
> “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.”
> Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>`
> field must mandatorily be “EUR”.

As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field
(assuming the company currency is always EUR for `l10n_it`).

Ticket [link](https://www.odoo.com/odoo/project.task/5913088)
opw-5913088

Forward-Port-Of: odoo/odoo#249272
Forward-Port-Of: odoo/odoo#247537

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

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

Currently, a user can add a timesheet entry with a negative Hours Spent 
value `exceeding six digits`.

**Steps to reproduce:**
- Install the `timesheet_grid` module.
- Open the `Timesheets` app and click `Add a line`.
- Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000).

**Observation:**
The line is added without any warning, whereas entering a positive 
value with more than six digits correctly raises an `error`.

**Root cause:**
At [1], the constraint validates only positive values exceeding six digits. 
As a result, negative values with more than six digits are not checked 
and bypass the `UserError validation`.

**Fix:**
This commit updates the constraint to ensure the six-digit limit 
applies to both positive and negative values.

[1]:
https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49

opw-5909417

Forward-Port-Of: odoo/enterprise#108182
Forward-Port-Of: odoo/enterprise#106781

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

### Steps to reproduce:
- Download MRP app.
- Create a product and its corresponding BOM (including at least a single operation)
- Create and confirm a manufacturing order for 1 unit of that product
- Click on the Shop Floor smart button > Click on the header of the MO
- The MO filter applied on the shopfloor search bar is removed

### Issue:
The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292
the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter.

### Fix:
Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context.
For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour.

opw-5877418

Forward-Port-Of: odoo/enterprise#107121

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

Steps to reproduce:
1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse).
2. Generate a payslip for this employee.
3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV).
4. Observe that the employee's name is displayed instead of the account holder's information.

Issue:
Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder.

Solution:
Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner:
- Updated QWeb templates to display bank.partner_id.name for account allocations.
- Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID.
- Ensured a fallback to the employee's legal name remains in place.

opw-5357652

Issue can be reproduced on a trial/SaaS db:
- Have an alias [alias] set up for vendor bills journal
- Create another company [company2]
- Add user [user] that can only access [company2]
- Add email [mail] as login/mail of that user
- Now from [mail] send a message, with pdf attachment, to [alias]

Issue: Mail will bounce back with an error
```
odoo.exceptions.UserError: Incompatible companies on records:
- “Draft Bill ” belongs to company “False” and “Journal” (journal_id: \'Vendor Bills\') belongs to another company.
```
This does not occur if [MAIL] is not associated with an user of company2

When the email is processed, the system recognizes the user email and
we have a minimal context.
Then, during move creation, `_compute_company_id` is called to assign
the company to the first accessible company.
However no accessible company is found because:
- current company would be the vendor bill journal's company ([company1])
  https://github.com/odoo/odoo/blame/0aa729fd6492139869bab299d1091a54fd443c54/odoo/addons/base/models/res_company.py#L390
- because of the lack of `accessible_companies` in environment,
  accessible companies is [user]'s company, [company2]
  https://github.com/odoo/odoo/blame/0aa729fd6492139869bab299d1091a54fd443c54/odoo/api.py#L682

As result, no company is assigned to the newly created move and it
raises an error when inconsistencies are checked

A solution is to force the company whenever we detect the move is
created from an alias

[1] Full traceback
```
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 1389, in message_process
    thread_id = self._message_route_process(message, msg_dict, routes)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 1282, in _message_route_process
    thread = ModelCtx.message_new(message_dict, custom_values)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_move.py", line 5894, in message_new
    move = super(AccountMove, move_ctx).message_new(msg_dict, custom_values=values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 1424, in message_new
    return self.create(data)
           ^^^^^^^^^^^^^^^^^
  File "<decorator-gen-67>", line 2, in create
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 479, in _model_create_multi
    return create(self, [arg])
           ^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_move.py", line 3125, in create
    moves = super().create(vals_list)
            ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<decorator-gen-40>", line 2, in create
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 480, in _model_create_multi
    return create(self, arg)
           ^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 267, in create
    threads = super(MailThread, self).create(vals_list)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<decorator-gen-0>", line 2, in create
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 480, in _model_create_multi
    return create(self, arg)
           ^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5018, in create
    records._check_company()
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4368, in _check_company
    raise UserError("\
".join(lines))
odoo.exceptions.UserError: Incompatible companies on records:
- “Draft Bill ” belongs to company “False” and “Journal” (journal_id: \'Vendor Bills\') belongs to another company.
```

opw-4232030