**Steps to reproduce the issue:**

- Install the l10n_mx_edi module.
- Open the Accounting app and go to Customers → Invoices.
- From the invoice line, make the Tax Object field visible.
- Create a new invoice and add a product that has no Unit Price.
- Save the invoice.
- Edit the same invoice, set a Unit Price for the product, and save it again.
- Issue: The Tax Object field is not automatically set after the Unit Price is added.

**Description:**

- In our standard code, there is a condition that skips computing the Tax Object when the Unit Price is [0](https://github.com/odoo/enterprise/blob/615a5f756d708db95e22cdbdd6e7aca72ac769ec/l10n_mx_edi/models/account_move.py#L988). This is the expected behavior.
- However, after setting a Unit Price on the product, the Tax Object is not recomputed, so it remains unset.
- To resolve this issue, I added price_unit to the @api.depends decorator so that the Tax Object is recomputed whenever the Unit Price changes.

**Reference videos:**

Before the fix:
[screen-capture (2).webm](https://github.com/user-attachments/assets/c1162fd9-52b8-4a8c-9ac2-39cf2ca3ad69)


After the fix:
[screen-capture (1).webm](https://github.com/user-attachments/assets/1c05dc34-6778-487a-9bfc-635cf652e670)


OPW -6305080 
UPG - 4268848

Forward-Port-Of: odoo/enterprise#123009

Version - 19.0

Steps to reproduce(runbot):
- Install `l10n_au_hr_payroll`
- Go to Payroll -> Configuration -> Super Accounts
- Create a Super Account by filling all the required fields
- You will encounter the issue
**TraceBack:**
```
('hr.menu_hr_employee_payroll', 485, 'Employees > Employees', 756):
 Traceback (most recent call last):
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 346, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 537, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 570, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6688, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1744, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1915, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 484, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4954, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/19.0/l10n_au_hr_payroll/models/hr_employee.py", line 118, in _compute_proportion_warnings
    proportions[emp.id] * 100,
 KeyError: 4
```
Issue:
During the refactoring from `read_group()` to `_read_group()`, the `proportions` dictionary became keyed by `hr.employee` records instead of employee IDs. While the condition was updated to use `proportions.get(emp)`, the warning message still accessed the dictionary using `proportions[emp.id]`, resulting in a `KeyError`.

Fix:
Use the employee record consistently when accessing the `proportions` dictionary after switching to `_read_group()`.

Task ID - 6390373
Refrence:
https://github.com/odoo/enterprise/pull/72217/changes#diff-8ae3564d54e47eec919ef273d44f6276d8c6df60e21c5c8c8f7292b1c38cf541R460

Forward-Port-Of: odoo/enterprise#124478

In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size.

Steps to reproduce:
-------------------
* Create a product with a bom that has a batch size of 2
* Open MPS
* Add the product
  - without specifying the bom
  - Route Manufacture
* Add 1 in the Forcast Demand -> the batch size from the bom it's not taken into account.

Observation:
-------------
When updating mps, it will call get_production_schedule_view_state: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L424 this function when calculating the quantity to resplenish will call _get_resplenish_qty: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L534 to know the quantity to resplenish it will need the batch size, in mps they will only consider the batch size from the bom registered: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L863-L865 
Since there is no default value for bom_id, If there is no bom selected, there is no batch size.

opw-6259956

Forward-Port-Of: odoo/enterprise#119560

Backport of : https://github.com/odoo/odoo/pull/269057 to  V18 
When an international customer selects an in-store pickup location, the
order's fiscal position changes to the fiscal position matching the pickup
warehouse. However, the order-line taxes and checkout summary are not
recomputed immediately.


**Steps to reproduce:**

1. Configure a French company and website.
2. Configure a product priced at 100  ( just an example , any price will do ) EUR excluding 20% French VAT.
3. Configure an export fiscal position removing VAT for Japan.
4. Configure an international delivery method.
5. Configure an in-store pickup method with a warehouse located in France.
6. Checkout using a Japanese delivery address.
7. Select the international delivery method.
8. Switch to pickup in store.

**Current behavior:**

- The order fiscal position changes to the French fiscal position.
- Product-line taxes and the checkout summary remain based on the export
  fiscal position.
- French VAT only appears later on the payment step.
- Switching back to international delivery can similarly leave stale totals.

**Expected behavior:**

- Selecting the French pickup location immediately applies French VAT.
- Switching back to international delivery immediately removes French VAT.
- Totals displayed during delivery selection match the payment-step totals.

**Cause:**

The Click & Collect flow explicitly recomputes `fiscal_position_id` when
selecting or leaving an in-store pickup location, but it does not recompute
the order-line taxes and prices.

Additionally, the pickup-location route does not return updated order-summary
values, so the checkout page cannot refresh its displayed totals.

**Solution:**

- Recompute taxes and prices when the in-store fiscal position changes.
- Restrict the recomputation to draft website orders.
- Return the updated order summary after selecting a pickup location.
- Refresh the checkout summary using the returned values.

**Tests cover:**

- Japanese delivery with export fiscal position and no VAT.
- Switching to a French pickup location immediately applying 20% VAT.
- Switching back to international delivery removing VAT.
- Delivery-step totals matching payment-step recomputation.
- Pickup-location route returning updated summary values.

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

Forward-Port-Of: odoo/odoo#276201
Forward-Port-Of: odoo/odoo#269086

### Steps to reproduce

1. Trigger an error whose browser object has no `stack` property (for example, a `DOMException` such as `AbortError`).
2. Let the web error service format its traceback.

### Current behavior

`formatTraceback()` calls `error.stack.split(...)` unconditionally, which raises a second `TypeError` and masks the original error.

### Expected behavior

The original error is formatted and reported even when the browser does not provide a stack trace.

### Fix

Use the existing technical name and message as the traceback when `stack` is absent. A focused regression test covers an `AbortError`-like object without `stack`.

### Tests

- `git diff --check`
- `node --check addons/web/static/src/core/errors/error_utils.js`
- `node --check addons/web/static/tests/core/errors/error_service.test.js`
- `@web/core/errors` HOOT suite: 24 tests, 107 assertions passed.

---

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

Forward-Port-Of: odoo/odoo#276864

### Issue before this commit:
Sending a TicketBAI invoice to a customer with a Spanish address and a VAT number starting with 'N' (Non-resident entity) resulted in a rejection with error B4_2000027. The XML incorrectly generated the national <DesgloseFactura> tag instead of the required <DesgloseTipoOperacion> tag.

### Steps to reproduce the issue:
1. Download Accounting, l10n_es and l10n_es_edi_tbai
2. Change name to ES Company into “NOMBRE APELLIDOUNO APELLIDODOS” (this is to make sure the certificate for Ticketbai works)
3. Go to Settings → Spain Localization → set Tax Agency for = Bizkaia
4. Change VAT number for customer Mulhacén Digital S.L. into N0011452J (must be a foreign entity ID)
5. Go to Settings > Technical > System Parameters and set the parameter 'l10n_es_edi_tbai.epigrafe' to 165360
6. Create a new invoice for that client and try to send it to TicketBAI
7. Error:  B4_1000002: Todos los registros incluidos en la petición son incorrectos. B4_2000027: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando la factura es completa y, además, existe destinatario extranjero (tipo IDOtro o que sea NIF que empiece por N) o la Clave de IVA es 02.

### Cause of the issue:
The _l10n_es_is_foreign() method evaluated these customers as domestic because their country was set to Spain and their VAT did not start with "ESN". It failed to recognize a standalone "N" prefix as a valid foreign identifier.
https://github.com/odoo/odoo/blob/75ae45861e2f417aa2b90bdb2b2869718e091c09/addons/l10n_es/models/res_partner.py#L7-L10


### Reason to introduce the fix:
Adding the 'N' prefix to the _l10n_es_is_foreign() check ensures the system correctly treats these entities as foreign for tax purposes. This generates the correct XML structure automatically, without forcing users to unnaturally prepend "ES" to a legally valid NIF.

opw-6326359

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

Forward-Port-Of: odoo/odoo#275231

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277425

**Steps to reproduce:**

- Create an attribute of type always, 2 values A and B for it
- The two values should have an extra price, like 100 for A and 150 for B
- Create an attribute of type dynamic, 2 values C and D for it
- C should have an extra price of 100 and 150 for D
- Make a product with both of those product, set the price to 100

2 possibilities:

- In the PoS, click the product, on the product popup, the price is 100
- This 100 is the product's price and does not change even if we change the values
- Order that product and buy it with variants A and C
- Click on the product again, the price is 300, which is correct
- When we click on D, the price is reset to 100, but should be 350

**Why the fix:**

When computing the popup's title, we try to get the current product based on the variants choices in the popup. If the product is found, we take that, because it means that it's already in the database.

https://github.com/odoo/odoo/blob/0d7f5058664b501779b833609468e535b34356bf/addons/point_of_sale/static/src/app/components/popups/product_configurator_popup/product_configurator_popup.js#L260

If we do not find it, we just take the product template, which does not contain the current extra prices, which is why we got a price of 100 in the exemple.

The product is not found because in the case of dynamic variants, the product is only created once it has been ordered at least once. Which means that for this newly created product, it is not yet in the database, so we take the product template instead of the product itself.

We now also add the extra price for a product if it is undefined, meaning it has not been found in the database yet.

We can't directly update the getter for the priceExtra, as it's also used to build the payload. As the rest of the code works fine with dynamic products with extra price the way it is sent now, we only change the title instead of changing the entire logic and computation.

opw-6326125

Forward-Port-Of: odoo/odoo#273411

**Description of the issue/feature this PR addresses:**
----------------------------------------------
On mobile devices, the meeting view had two UI issues affecting the call
experience.
The call permission dialog could display an unwanted focus outline around
its content because the dialog body was focused on touch devices.
Additionally, meeting action buttons could be partially hidden,
especially in portrait mode, as the meeting view could extend beyond the
visible viewport height.

**Current behavior before PR:**
----------------------------------------------
- Opening the call permission dialog on mobile could show an unwanted
  focus outline around the dialog content
- Meeting action buttons could be partially hidden on mobile devices
- In portrait mode, the footer could overflow below the visible viewport


**Desired behavior after PR is merged:**
----------------------------------------------
- Call permission dialog opens on mobile without showing the unwanted
focus outline on main body.
- Meeting action buttons remain fully visible on mobile devices


Task-6232825

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

Problem:
Some users with limited access rights cannot access invoices they created, after another user duplicates their sales order and invoices it.

Steps to reproduce:
1. Create a user with minimal access rights (only access rights to their own sales orders and invoices).
2. Sign in as that user and create a sales order and confirm it.
3. Create an invoice for that sales order and validate it.
4. Sign in as an administrator and create a duplicate sales order for that sales order, but assign it to a different user (not the one created in step 1).
5. Confirm the duplicate sales order, create an invoice for it and validate it.
6. Sign in as the user created in step 1 and try to access the invoice created in step 3.
7. Note the access error

Cause:
When reading an account.move record, the system searches for duplicate moves and adds them to the duplicated_ref_ids field. However, it does not check if the user has read access to those duplicate moves, which leads to access errors when trying to access the main account.move record (which the user has read access to) because the system tries to read the duplicate moves (which the user does not have read access to).

opw-6374566

Forward-Port-Of: odoo/odoo#276547