#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
  - "You can send this invoice electronically via Peppol." (what is peppol)
  - "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
  (this warning can be disabled by setting the system parameter
   `account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning

If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
  - it explains what French E-Invoicing is
  - it provides a button to open the registration wizard
  - in case the company is registered on Peppol it deregisters the
    company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
  also for French companies (with the wording and "Peppol Info" mentioned above)
  - It is displayed in case we are opening the Send & Print wizard from a French
    company for a partner on peppol but the "Peppol" / "French
    E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
  the user to register

In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success

task-6320246

#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case

That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.

task-None

Forward-Port-Of: odoo/odoo#272208
Forward-Port-Of: odoo/odoo#271733

### Issue:
When printing the Planning report (PDF) and grouping by a field other than Employee (e.g., Role, Project, or a Char/Selection field), the server crashes with a `TypeError` or `AttributeError`.

### Cause:
The `action_print_plannings` method hardcoded the assumption that the `group_by` key would always be a `resource.resource` recordset.
1. When the user grouped by other fields, it returned strings, booleans, or empty recordsets, causing crashes when the code blindly called `.id` and `.display_name`.
2. During the sorting phase, mixing `False` (for unassigned empty recordsets) with strings caused a `TypeError`.
3. For multi-day shifts, the method failed to extract the actual resource to calculate the shift splits if the grouping was not explicitly set to `resource_ids`.

### Fix:
- Implement safe attribute checks (`hasattr`) when extracting group IDs and display names.
- Ensure unassigned empty recordsets properly fall back to the "Undefined" string and empty strings during sorting to prevent TypeErrors.
- Universally fallback to extracting the resource directly from the slot (`slot.resource_ids[:1]`) for multi-day time splitting when grouped by non-resource fields.
- Add a unit test to ensure stability when grouping by `role_id` with multi-day shifts.

Task: 6244057

Forward-Port-Of: odoo/enterprise#118530

## Description of the issue/feature this PR addresses:
Setup plus video
1. Go to settings, enable "Automatic Valuation" and "Storeable Locations".
2. Navigate to Product Categories.
3. Create a new product category with the costing method Standard Price and the inventory valuation Automatic.
4. Navigate to Products, click into any product.
5. Add the new product category to this product under General Information.
6. Add any tax in the purchase tax field.
7. In the Accounting tab of the product, add any account to the Price Difference Account field.

https://drive.google.com/file/d/1i2DHEt0g9G5Edad_QB3QaFkOT49cbMAZ/view?usp=sharing

Instructions to reproduce error
1. Navigate to Purchase.
2. Add a customer, then add the configured product.
3. Add a tax to the line. Ensure that the tax and price_unit are nonzero.
4. Confirm the order.
5. Receive the product.
6. Create the bill.
7. Edit the tax on the vendor bill, then save the changes. Notice that the changes are kept.
8. Select Confirm. Notice that the changes to the tax line are not kept, and that the COGS lines appeared (with taxes applied to them).
9. Reset the bill to draft.
10. Click into the configured product and remove the product category.
11. Repeat steps 7-8 . No COGS lines, and the tax line is the manually set value.

## Current behavior before PR:
COGS lines with taxes have no net effect on any tax lines as they cancel each other out. However, their creation triggers the recalculation of all tax lines, undoing any manual adjustments to tax lines.

## Desired behavior after PR is merged:

This commit ensures that COGS lines are not considered base tax lines, so that their creation does not trigger the recalculation of other base tax lines.

opw-5387248


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

Forward-Port-Of: odoo/odoo#271262
Forward-Port-Of: odoo/odoo#262442

## [FIX] base: Fix vat label css
With the wrapping div the label lost it's label style.

task-6352123

## [FIX] l10n_*: Fix xpath after multi ID
* l10n_br,l10n_my_ubl_pint,l10n_ca,l10n_ph,l10n_in,l10n_rs_edi

In the multi ID [1], we completely revamped the UI around the `vat` field.
It's now mostly made of:
- the VAT field inlined with a "+" button adding additional_identifiers
- the additional identifiers that comes below with input-text-like display.
The feature should stay in one block, therefore we added an "identifiers" div
wrapping all these fields/buttons/labels.
This way other fields can easily xpath before or after the whole block.
We also have a vat_div identifiers that is meant for feature needed to be inlined
with the vat and the "+".

This PR and its Enterprise counterpart fix some xpath that were still incorrect
after [1] and [2] in following modules:
l10n_br, l10n_my_ubl_pint, l10n_ca, l10n_ph, l10n_in, l10n_rs_edi, l10n_mx_edi_stock

[1]: https://github.com/odoo/odoo/pull/262274
[2]: https://github.com/odoo/odoo/pull/271906
task-6352123

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

**Current behavior before PR,**
Computing `main_user_id` of a partner involved filtering active users within a
loop. To avoid losing the prefetching, we manually forced all partner users to
be kept in the prefetch during each iteration. This caused performance issues as
the recordset grew large (e.g., during auto-subscription).

**Desired behavior after PR is merged,**
All partner users are prefetched and filtered once, removing the need for a
repetitive manual prefetch.

**Benchmark,**
The following observations were recorded when auto-subscribing users to a
discuss channel at different scales.
The _Before_ and _After_ results represent the max values from three consecutive
tests.

|  Records |   Before |      After |
| :--------| -------: | ---------: |
|    3k    |   ~2.3s  |    <90ms   |
|    5k    |   ~3.8s  |    <160ms   |
|    10k   |   ~7.6s  |    <300ms  |

part of task-6116079



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

Forward-Port-Of: odoo/odoo#271549

Issue:
----------------------------------------
When changing multiple times the hours of a slot to include out-of-schedule time.

Steps to reproduce:
----------------------------------------
- Have planning_field_service installed
- Have an employee with a schedule from 7am to 3pm
- In planning view, create a new slot for this employee from 7am to 3pm (8h)
- Change the starting hour to 6am (8h + 1h of break time)
- Change it back to 7am
- The slot shows 7h07 of allocated hours and 53 minutes of break time

Cause:
----------------------------------------
Since 8ca9faabfdf7d15883ba52da47bd8c562cf601de the compute of `allocated_percentage` is overriden in `planning_field_service`. The new compute uses `break_time` to recompute `allocated_percentage`. `break_time` is the not work time over the whole duration of the slot, including hours out of schedule.

But the definition of `allocated_percentage` in `planning` is: the percentage of slot hours in schedule which are actually worked. So when changing the start to 6am `allocated_percentage` is still supposed ot be 100% because the employee is working 100% of the hours he is supposed to work considering its schedule.

With the actual code `allocated_percentage` is actually computed as 8/9 = 0.88888... because it will take into account the hours out of schedule.

As `allocated_percentage` is not recomputed if `allocated_hours` or `break_time` aren't modified by the user. It is then used [here](https://github.com/odoo/enterprise/blob/ae5008bdaf1b87269083f82280c7df44390129ff/planning/models/planning_slot.py#L2865-L2867) to compute the allocated_hours and the number of hours in schedule is divided base onthe percentage.

Solution:
----------------------------------------
We only consider the hours in schedule to recompute `allocated_percentage`.

`allocated_percentage` was used in `_onchange_break_time()` to get the previous ratio and calculate the allocated hours from which we deduct the break time. We cannot do this now so we also need to compute the working hours.

-----------------------------------------

# [FIX] planning_field_service: handle input of negative break_time

Issue:
----------------------------------------
When inputting negative break_time for a slot, it's possible to get a traceback.

Steps to reproduce:
----------------------------------------
- Have planning_field_service installed
- Have an employee with a schedule from 7am to 3pm
- In planning view, create a new slot for this employee from 7am to 3pm (8h)
- Input 9h of break time
- Input -1h of break time
- Traceback

Cause:
----------------------------------------
When `slot.allocated_hours` is 0 and we input a negative value in `break_time`, the code in `_onchange_break_time()` will give `allocated_hours` the positive value of `break_time` making them opposite.

Then in [`_compute_allocated_percentage()`](https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/planning_field_service/models/planning_slot.py#L98) we divide by their sum, which equals 0.

Solution:
----------------------------------------
We compute the divider part and check if it's zero in `_compute_allocated_percentage()`.

Also add a `max()` in `_onchange_break_time()` to convert the negative break time in allocated hours and resets `break_time` to zero.
This ensures the same behavior as inputting negative values in `allocated_hours`.

opw-6273559

Forward-Port-Of: odoo/enterprise#122209
Forward-Port-Of: odoo/enterprise#121168

The following error is raised in the POS when paying with an Adyen terminal:
```
TypeError: Cannot read properties of undefined (reading 'uuid')
at Proxy.handleAdyenStatusResponse
```

Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes.

opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference.

Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch.

opw-6237987

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

Forward-Port-Of: odoo/odoo#271181
Forward-Port-Of: odoo/odoo#269720

Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased.

For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`.

However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision.

This is inconsistent with sales: sale order lines preserve very small unit prices correctly.


**Current behavior before PR:**

A product with `standard_price = 0.001235` keeps that value on the product form.

When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost.

The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line.

**Desired behavior after PR is merged:**

Purchase order lines preserve the computed unit price precision, just like sale order lines already do.

A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision.

---

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

Forward-Port-Of: odoo/odoo#270860
Forward-Port-Of: odoo/odoo#267941

### Issue:
On invoices in SA and AE, the invoice title was always rendered in English even when the customer's language is Arabic

### Cause:
In 19.2, the report view `report_invoice_document` was refactored to require `t-set` declarations before `t-call`
In 19.1, `o` was reassigned early with the customer language via `t-value="o.with_context(lang=lang)"`, so all subsequent calls on `o` inherited the correct language
https://github.com/odoo/odoo/blob/3d2d8cc498a56faac31e95fb854a94e4011d812d/addons/account/views/report_invoice.xml#L4-L6

After the refactor, `o` no longer carries the customer language context at the point where `l10n_gcc_settings` is evaluated `_l10n_gcc_get_invoice_title()` was therefore called with the connected user's language instead of the customer's

### Steps to reproduce:
- Install `l10n_sa` or `l10n_ae` and switch to the corresponding company
- Create and confirm an Invoice (any data)
- Set the customer language to Arabic
- Print the Invoice

Before the fix, the invoice title is displayed in English

opw-6333472

Forward-Port-Of: odoo/odoo#272865

Steps to reproduce
------------------
1. Install l10n_ke_edi_oscu_pos.
2. Select the Kenyan company.
3. Enable eTIMS on the PoS.
4. Register the products inside a combo, but not the combo itself.
5. Sell the combo in the PoS.

Observation
-----------
We see a warning that the combo must be registered to eTIMS, and the order can't be validated.

What's happening
----------------
In the PoS a combo adds a 0 price parent line for the combo product, but the combo is not a real item to send to eTIMS, only the products inside it are, and (as per step 4) the combo is not registered.

`checkEtimsFields` sees the combo as not registered, so it raises the warning in `showUnregisteredProductsWarning` and blocks the payment in `validateOrder`.

Fix
---
In the backend, we skip sending the parent combo line to eTIMS, and on the frontend, we make the combo parent line not need eTIMS registration, so the warning and the block don't apply to it.

opw-6253306

Forward-Port-Of: odoo/enterprise#122179
Forward-Port-Of: odoo/enterprise#119362

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122398
Forward-Port-Of: odoo/enterprise#122030

Steps to reproduce:
- Install `l10n_in_reports` module(Indian Localisation)
- Create a branch in `IN Company` > Select both
- Create separate invoices for each company
- Created the GSTR-1 report for both company
- While generating Excel, select only main company

Traceback:
```py
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 2537, in action_generate_gstr1_xlsx
gstr1_json = self._get_l10n_in_gstr1_json()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 1071, in _get_l10n_in_gstr1_json
'b2cs': _get_b2cs_json(AccountMoveLine.search(self._get_section_domain('b2cs'))),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 672, in _get_b2cs_json
for line, line_tax_details in tax_details.items():
^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'items'
```

Cause:
This issue occurs because, while generating the GSTR-1 Excel report for a particular month, [journal_items] contains account moves from both companies. This happens because the [domain] fetches records for both companies, resulting in move [lines] from both companies being included.

However, while generating the Excel report, only one company is selected. As a result, [tax_details_by_move] does not contain the move data for the branch company, which returns None, causing the error to be raised.

Solution:
Pass an empty `{}` for `tax_details` when only a single company is selected.

[journal_items]: https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L877 
[domain]: https://github.com/odoo/enterprise/blob/770ffaac14bfcd2c54a7ce6aca27e0010e7884d4/l10n_in_reports/models/account_return.py#L1387-L1393 
[lines]:
https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L1074 
[tax_details_by_move]:
https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L880

opw-6242824

Forward-Port-Of: odoo/enterprise#118614

**Steps to Reproduce:**
- Install the Accounting and Contacts modules.
- Enable Quick Encoding for Customer Invoices and Vendor Bills in the company 
  settings.
- Create a new customer: Assign a salesperson.
- Ensure:
  - The salesperson is not a login user.
  - The customer language, salesperson's language, and Login user's language 
    are different. Example:
     - Customer language: English
     - Salesperson language: French
     - Login user language: French
- Create a customer invoice using the Upload Document functionality.
- Select the customer created above.
- Use Quick Edit mode and enter an amount and Click Confirm.

**Issue:**
- When the invoice notification is rendered in a language different from the one
  used during the write operation, the notification rendering flow calls 
  _notify_by_email_prepare_rendering_context().
- During rendering, the code executes:
```
self.tax_totals.get('total_amount_currency', 0)
```
- Since tax_totals is protected, the ORM returns False instead of the expected
  dictionary, leading to:
```
AttributeError: 'bool' object has no attribute 'get'
```

**Root Cause:**
- This issue occurs in Quick Edit mode because tax_totals is [not read-only](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/views/account_move_views.xml#L1359) 
  in Quick Edit mode and is included in [the values](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/web/static/src/model/relational_model/record.js#L708) sent by the web client during write().
- During create()/write(), _get_protected_vals() marks tax_totals as protected.
- Since tax_totals is a [@api.depends_context('lang')](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L975) computed field, it 
  maintains a separate cache per language. [During write()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3955), the [field becomes 
  protected](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3863) by [env.protecting()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/odoo/orm/fields.py#L1738). While the protection is still active, the mail 
  notification flow renders the email using the recipient's language. If the 
  corresponding language-specific cache entry for tax_totals is not available, 
  the ORM cannot recompute the protected field and returns False instead 
  of the expected dictionary.

- The rendering code assumes tax_totals is always a dictionary and directly 
  calls  .get(), leading to the crash.

**Solution:**
- Exclude tax_totals from _get_protected_vals().
- tax_totals is already handled explicitly after create()/write(), so protecting 
  it is unnecessary. This allows the field to be recomputed during notification 
  rendering when required.

**Result:**
- Invoice notifications render correctly in all languages.
- No RPC crash occurs when rendering notifications after Quick Edit.

**Runbot reproduction: [video](https://github.com/user-attachments/assets/5f045efb-37de-40aa-b135-1368b1601d61)**

**opw-6209647**

Forward-Port-Of: odoo/odoo#266335

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

# How to reproduce
- Create a new Receipt
- Save
- Delete the new Receipt

# The issue
A traceback is shown :
`TypeError: Cannot read properties of undefined (reading 'label')`

# Cause
This is caused by the custom status bar for pickings `StockPickingLockedStatusBarField`. In its template, we replace the display of the current label : https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L20-L23 https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L4-L9

The issue is that the base implementation of the current label properly handles the case were no item is currently selected:
https://github.com/odoo/odoo/blob/7630f8fe2d5198b7a1ed538241795dc26a497fa0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L298-L300

But the picking implementation does not :
https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.js#L12-L14

And it seems that the template is quickly rendered without any selected item before deletion.

opw-6345192

Forward-Port-Of: odoo/odoo#273030

Steps to reproduce:
- Install `l10n_in_reports` module(Indian Localisation)
- Create a branch in `IN Company` > Select both
- Create separate invoices for each company
- Created the GSTR-1 report for both company
- While generating Excel, select only main company

Traceback:
```py
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 2537, in action_generate_gstr1_xlsx
gstr1_json = self._get_l10n_in_gstr1_json()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 1071, in _get_l10n_in_gstr1_json
'b2cs': _get_b2cs_json(AccountMoveLine.search(self._get_section_domain('b2cs'))),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 672, in _get_b2cs_json
for line, line_tax_details in tax_details.items():
^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'items'
```

Cause:
This issue occurs because, while generating the GSTR-1 Excel report for a particular month, [journal_items] contains account moves from both companies. This happens because the [domain] fetches records for both companies, resulting in move [lines] from both companies being included.

However, while generating the Excel report, only one company is selected. As a result, [tax_details_by_move] does not contain the move data for the branch company, which returns None, causing the error to be raised.

Solution:
Pass an empty `{}` for `tax_details` when only a single company is selected.

[journal_items]: https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L877 
[domain]: https://github.com/odoo/enterprise/blob/770ffaac14bfcd2c54a7ce6aca27e0010e7884d4/l10n_in_reports/models/account_return.py#L1387-L1393 
[lines]:
https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L1074 
[tax_details_by_move]:
https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L880

opw-6242824

Forward-Port-Of: odoo/enterprise#118614

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page.

### Steps to reproduce

1. Enable multi-company and create a second company `Company B`.
2. Create two websites with different domains, one per company:
   - `Website A` on the main company, domain `http://website-a.test`
   - `Website B` on `Company B`, domain `http://website-b.test`
3. Set the system parameter `web.base.url` to `http://website-a.test`. System parameters are global, so this value applies to the whole database regardless of the company you switch to.
4. Create a contact and set its `Company` field to `Company B`.
5. In Email Marketing, create a mailing with recipient model `Contact`, target the contact above, pick any template with an unsubscribe link, and send it.
6. Open the email in an incognito window and click the unsubscribe link: you land on the login page instead of the unsubscribe page.

### Cause

Mass mailing builds the unsubscribe link in two steps.

First, each email body is rendered for its recipient. While rendering, relative URLs like `/unsubscribe_from_list` are turned into absolute URLs by prepending a base URL. That base URL comes from the recipient record itself: `recipient.get_base_url()`. The `website` module overrides this so that, when the record has a company, it returns that company's website domain. For a contact in `Company B`, the body ends up with `http://website-b.test/unsubscribe_from_list`.

Second, right before sending, `mail_mail._prepare_outgoing_list` replaces that placeholder URL with a per-recipient signed URL pointing to `/confirm_unsubscribe`. It does this by plain string replacement: it looks for `{base_url}/unsubscribe_from_list` in the body and swaps it. The `base_url` used here came from `self.mailing_id.get_base_url()`. A mailing has no company, so its base URL falls back to the global `web.base.url`, which in our setup is `http://website-a.test`.

The two base URLs no longer match. The body contains the website B URL, but the replacement code searches for the website A URL. The search fails, the placeholder stays in the email, and the recipient clicks a link to `/unsubscribe_from_list`. That route only redirects to `/mailing/my`, which requires being logged in, so the user lands on the login page.

### Fix

Compute the base URL from the recipient record (the same record used when rendering the body) instead of the mailing. The two URLs then agree and the replacement works. Fall back to the mailing's base URL if there is no recipient model on the mail.

opw-4914203

Forward-Port-Of: odoo/odoo#273190
Forward-Port-Of: odoo/odoo#264055

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

## **Issue:**
When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by another salesperson.

## **Steps to reproduce:**
- Install sale_subscription_stock.
- Create a user with Sales: Own Documents Only and Inventory Administrator access rights.
- Create a sale order as another user.
- Validate the delivery with the restricted user.

## **Solution:**
During _action_done(), [This line](https://github.com/odoo/enterprise/blob/19.0/sale_subscription_stock/models/stock_picking.py#L45) is checking subscription_state. Since the user does not have read access to the sale order, reading this field raises an access error and prevents the delivery from being validated. As the method only needs to read the subscription state, access the field with sudo() to avoid the unnecessary access error while preserving the existing business logic.

Runbot Video : [Video](https://drive.google.com/file/d/1d7U2jTCxaaVk2YJcy3bi2SlYuT-yXMsu/view?usp=drive_link) 

OPW - 6295712

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

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

Since 17.0, `webp` images can be uploaded at any resolution, whereas every other format is refused above IMAGE_MAX_RESOLUTION (50 Mpx) when the attachment is created on the server.

Root cause
===========
`ImageProcess` grouped webp together with empty sources and SVG and set `self.image = False`, returning before the `verify_resolution` check. As a result the resolution limit enforced for `png/jpeg/...` was never applied to `webp`.

Fix
===
Split `webp` out of the skip branch: it is still not processed as before, but its resolution is now read from the RIFF header with `get_webp_size()` and checked against `IMAGE_MAX_RESOLUTION`, so oversized webp images are refused on upload like any other format.

Steps to reproduce
===================
1. Edit any page with the website editor
2. Upload a `webp` image larger than 50 Mpx (e.g. 8000x8000)

=> The image is accepted, while a `png/jpeg` of the same size is refused

task-4134430

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

Forward-Port-Of: odoo/odoo#273010