Steps to Reproduce:
1. Open the website module.
2. Open the media upload dialog to upload an image by either
double-clicking the logo or replacing the existing image.
3. Upload a large file.
4. Abort the upload before it finishes by clicking the 'Discard'
button in the media dialog box.
After performing these steps, a traceback is observed.

Before this commit:
- Image upload failures would throw uncaught exceptions.
- These exceptions would interrupt the flow and result in a poor user
experience with no clear feedback.
- Even after clicking the discard button the image was still
getting uploaded.

After this commit:
- Uploads can be safely aborted when the media dialog is discarded.
- Ongoing XHR requests and RPC calls are properly cancelled.
- The upload loop stops immediately when an abort is triggered with
no traceback.
- Users get a predictable and clean exit instead of a broken state.
- Files are no longer uploaded after clicking Discard.

### task-4752497

Forward-Port-Of: odoo/odoo#219081

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

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

## Issue Before This PR:
The fields `used_weight_percentage` and `used_volume_percentage` in the
list view were showing incorrect values. These fields were incorrectly
aggregating totals across all batches, as the calculation of
`estimated_shipping_weight` and `estimated_shipping_volume`
was not handled per batch, resulting in wrong percentages.

## Steps to Reproduce:
- install inventory module and enable settings for
  batch transfers and dispatch management,
- add two batch records with vehicles assigned
  (having weight or volume capacity), and transfers
  having products with weight or volume defined
- Observe different values of weight % or volume %,
  in form and list view.

## Cause of the Issue:
In the method `_compute_estimated_shipping_capacity`
the computation loop referenced all records together,
causing totals to be shared across batches.

## With This PR:
Each batch now computes its own estimated shipping weight and volume correctly,
ensuring correct per-batch values consistent with the form view and
match what users see when opening individual records.

Backport of [commit](https://github.com/odoo/odoo/pull/227166/changes/a709e84d8357a622198a8ac0a0199af9b16f56e7)

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#247537

Steps:

- Activate automatic accounting
- Create a product P:
  • Storable, track inventory
  • Set a cost
  • Product category FIFO, automated valuation
- Activate analytic accounting
- Create a distribution model for that applies to expense account
- Create an invoice for product P, set an analytic (different from the
  one set on the model above)
- Confirm
-> On the cogs expense line, the analytic account is the one from the
   product line, it should be the one set on distribution model

Cause:

The analytic distribution is forced to the same value as the product
line at the creation of cogs lines.

Fix:

Adding a helper to know if we need to force the value of analytic
distribution or leave it to the compute method.
This is especially needed for invoices that are originated by a sale order linked
to a project, since we calculate profitability items regarding the
project's distribution.

Note:

This is an issue that has been addressed several times in differents
way, the reason of this fix is that we think that user should rely on
distribution models: if they want a distribution to be applied on the
cogs line, they should create a distribution model that meet their
needs.

opw-5193666

*: purchase_stock

Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `procurement group`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a procurement group, even when the transfers are manually created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.

Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were created    manually and not generated from any same source document like PO/SO.

Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `group_id` is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves without a `group_id` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common procurement group.

After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `procurement.group`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a procurement group. This ensures each manual transfer creates its `own next operation` in multi-step routes.

Task-ID: 5242340

**Steps to reproduce:**
- create a storable avco automated product
- in the purchase tab, select control policy : "on invoice quantitites"
- create and confirm a purchase order for 100 qty at 1 unit price
- on the picking, unhide the description column
- change the description for the move
- go back to the purchase order and change the quantity to 105
- (because we changed the description, the new move created 
with a quantity of 5 is not merged to the existing one of 100 and 
we now have two moves on the picking)
- create and confirm the bill
- validate the picking
- select the valuation smart button

**Current behavior:**
the svl with a quantity of 100 has a total value of 105
the svl with a quantity of 5 has a total value of 105

**Expected behavior:**
the svl with a quantity of 100 should have a value of 100
the svl with a quanitty of 5 shoul have a total value of 5

**Cause of the issue:**
When the picking is validated, action_done is created on the 
two moves. 
In the stock_account override: 
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 105.
- then product_price_update_before_done is called on the two 
moves before creating the svls.
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/stock_account/models/stock_move.py#L352

Inside product_price_update_before_done, for each move, 
we call _get_price_unit.
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/stock_account/models/stock_move.py#L426

For the first move, in the purchase_stock override 
of _get_price_unit : 
- to get the received qty we call _get_qty_received_without_self()
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L50
and because the super method of action_done was already called, 
qty_received of the purchase order line is 105, so _get_qty_received_without_self
will return 5. 
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L108-L113
So received_qty is 5 and later remaining_qty will be 100
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later 
remaining_value will be 105
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L60
Therefore price_unit will be 1.05 (105/100) instead of 1
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L95

For the second move, the problem is the same and 
the price unit ends up being 21 (105/5)

**fix**
We do not take into account the move(s) for the same product
of the same picking in the remaining value (because svls are not created yet)
so we should not take them into account in the remaining quantity.

the problem is very similar to https://github.com/odoo/odoo/pull/235601
In this other PR it happend because we had multiple move for 
the same product because they were in a batch, and in this PR we 
have the issue because we have multiple move for the same product 
because they didn't merge due to the description difference. 

opw-5429501