**Steps to reproduce:**
* install `l10n_lu_reports`.
* Create a company in Luxembourg with a `company_registry` number set.
* Link this company to an accounting firm that is a natural person (independent accountant) with no business registration number — i.e. `l10n_lu_agent_rcs_number` is left empty on the agent partner.
* Go to the tax report and generate the XML declaration.

**Observed behavior:**
* The `<Agent><RCSNbr>` field in the generated XML contains the company's own `company_registry` value instead of `NE`.
* The file is rejected by the Luxembourg tax administration.

**Cause:**
* In `l10n_lu_generate_xml.py`, the `agent_rcs_number` template value was built with a plain `or` chain: `agent.l10n_lu_agent_rcs_number or company.company_registry or "NE"`
* When an agent is set but has no RCS number (natural person), the fallback incorrectly continued to `company.company_registry` instead of stopping at `"NE"`.

**Fix:**
* Use a conditional expression so that `company.company_registry` is only used as a fallback when **no agent is linked** to the company: `(agent.l10n_lu_agent_rcs_number if agent else company.company_registry) or "NE"`

opw-6044689

Forward-Port-Of: odoo/enterprise#112968

**Steps to Reproduce**

1. Install the **Live Chat** module in version 18.4 or above.
2. Go to: **Settings → Users**
   * Open your user and change the access rights from **Live Chat / Administrator** to **Live Chat / User**.
   * Alternatively, create a new user giving him rights of the **Live Chat / User** group.
3. Login using the Live Chat user.
4. Open the **Live Chat** application and navigate to: **Live Chat → Sessions**
5. Open any existing session. The session and its messages are accessible without any issue.
6. In the search bar, click: **Filters → Custom Filter**
7. Select the field `Chatbot Messages (chatbot_message_ids)`. You will face the below traceback.

**Issue Description:**
The issue happens because `discuss.channel` records are accessible to users having the `im_livechat_group_user` group through the Sessions menu: https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/views/im_livechat_channel_views.xml#L310-L315

The field `chatbot_message_ids` is defined as:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/models/discuss_channel.py#L165

This field points to the `chatbot.message` model, but access to that model is restricted to `im_livechat_group_manager` only:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/security/ir.model.access.csv#L15

As a result, when a Live Chat user tries to use `chatbot_message_ids` in a custom filter, Odoo attempts to read `chatbot.message` records and raises an `AccessError`.

This issue started happening after the access rights changes introduced in pr : https://github.com/odoo/odoo/pull/201880

Specifically, the following ACL changes:
https://github.com/odoo/odoo/pull/201880/changes#diff-c1592d633a34db44a7cc2a527482cecc56127cbba72649e7318dcf63ccf477afR19-R20

**Solution:**
To fix this issue, added the group `im_livechat_group_manager` on the field `chatbot_message_ids` so only those user can access the field who belong to the group.

**Traceback:**

```.py
odoo.exceptions.AccessError: You are not allowed to access
'Chatbot Message' (chatbot.message) records.

This operation is allowed for the following groups:
        - Live Chat/Administrator

Contact your administrator to request access if necessary.
```

opw - [6169395]
upg - [4274573]



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

Forward-Port-Of: odoo/odoo#264682

### Issue:
When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format

According to the documentation, the options for Periodo include distinction between monthly and trimester (p224 - 225):
https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII-Descripcion-ServicioWeb-v1-1_es_es.pdf

### Cause:
The invoice JSON generation does not consider the company's `tax_periodicity`

This logic was probably omitted because `account_reports` may not be installed
However, when the periodicity is configured, the generated SII document should reflect it correctly

### Steps to reproduce:
- Install `l10n_es_edi_sii` and `account_reports`
- In Settings, set `Tax Periodicity` to `Quarterly`
- In Settings, set `Tax Agency for SII` to `Agencia Tributaria Española`
- Change ES Company vat number to `ESA12345674`
- Create an invoice (Date: 01/05/2026, Customer: ES Company)
- Open the generated JSON document
- Check the Periodo value, it should be 2T in May

opw-6050587

Forward-Port-Of: odoo/odoo#267708
Forward-Port-Of: odoo/odoo#264063

This commit will affect all certification modules for the POS (pos_blackbox_be, l10n_se_pos, l10n_de_pos_res_cert)

Inside the base `handleDecreaseLine` we match all the lines which have the same product_id and compute the new quantity based on those. At the end we create a new line with the decreased quantity. This method is called when `disallowLineQuantityChange()` returns `false`, so when either of `pos_blackbox_be`, `l10n_se_pos` or `l10_de_pos_res_cert` are installed.

The problem is that different combos will still have the same product_id and total_excluded_currency, so the
`current_saved_quantity` adds the other unrelated combos together and tries to remove from the total of all the combos with the same parent.

This commit will keep the decrease line for an order in the uiState. So instead of iterating over all the lines in the order and matching lines which have the same product_id we always keep track of the original line and the matching decrease line for that line.

Task-[6173236](https://www.odoo.com/odoo/project/1737/tasks/6173236)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#262744

When the cogs are computed using the Stock Moves values, we would not differentiate between deliveries and returns, taking both in the cogs value computation. This meant that when doing multiple deliveries with returns before posting the invoice, if the deliveries/returns had different cost, the COGS would be an average of all of them. Example: Delivery $10 -> Return $10 -> Delivery $20  ==>  COGS $13.33

## HOW TO REPRODUCE
- Create Product FIFO Perpetual, cost=10, onHand=1
- Create Sale order for 1 unit
- Deliver and return
- Change cost from 10 to 20:
  - Set on hand to 0
  - Change product cost to 20
  - Set on hand to 1
- Duplicate SO delivery and validate
- Create and Post Invoice => COGS == 13.33


## FIX EXPLANATION

Returns / Refunds are counted negatively.
So when we compute the moves value, instead of doing `(10 + 10 + 20) / (1 + 1 + 1)`, we do `(10 - 10 + 20) / (1 - 1 + 1)`.
We need to propagate this logic to the cogs quantity, so that we don't believe that we invoiced 3 units while only 1 (1-1+1) was delivered.

---

Note:
For the update in test `test_fifo_delivered_invoice_post_delivery_with_return`, I put back the original values modified by 5978bc5dc683d317f4ab87f6c9c9d843568bf4ea

---

<img width="1852" height="363" alt="image" src="https://github.com/user-attachments/assets/ea9f16b2-a818-4c21-b3c3-aa296792f477" />
<img width="1203" height="787" alt="image" src="https://github.com/user-attachments/assets/7348d15a-b840-4ee0-b1da-2b954cdb3d5e" />

---

## Test result without fix:
```
2026-05-28 11:57:45,899 36667 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: Starting TestAngloSaxonValuation.test_fifo_invoice_with_delivery_with_return ... 
2026-05-28 11:57:47,138 36667 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: ====================================================================== 
2026-05-28 11:57:47,138 36667 ERROR oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: FAIL: TestAngloSaxonValuation.test_fifo_invoice_with_delivery_with_return
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/sale_stock/tests/test_anglo_saxon_valuation.py", line 1099, in test_fifo_invoice_with_delivery_with_return
    self.assertRecordValues(invoice.line_ids, [
  File "/home/odoo/Odoo/src/19.0/odoo/odoo/tests/common.py", line 727, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'ac[22 chars]t': 0, 'credit': 50}, {'account_id': 9141, 'de[114 chars]: 0}] != [{'ac[22 chars]t': 0.0, 'credit': 50.0}, {'account_id': 9141,[132 chars]0.0}]

First differing element 2:
{'account_id': 9138, 'debit': 0, 'credit': 20}
{'account_id': 9138, 'debit': 0.0, 'credit': 13.33}

- [{'account_id': 9162, 'credit': 50, 'debit': 0},
+ [{'account_id': 9162, 'credit': 50.0, 'debit': 0.0},
?                                   ++           ++
-  {'account_id': 9141, 'credit': 0, 'debit': 50},
+  {'account_id': 9141, 'credit': 0.0, 'debit': 50.0},
?                                 ++             ++
-  {'account_id': 9138, 'credit': 20, 'debit': 0},
?                                 ^^
+  {'account_id': 9138, 'credit': 13.33, 'debit': 0.0},
?                                 ^^^^^           ++
-  {'account_id': 9168, 'credit': 0, 'debit': 20}]
?                                             ^^
+  {'account_id': 9168, 'credit': 0.0, 'debit': 13.33}]
?                                 ++            ^^^^^

```

---

OPW-6213321

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

Forward-Port-Of: odoo/odoo#266917

Issue
-----
Labels generated with DHL do not respect the template (dimensions) set on the
delivery method.

Steps to reproduce
-----
- Set up DHL
	- set label template as 6X4_A4_PDF
- Create a delivery using the method
- Validate the delivery

> The generated label is in 8x4 inch format instead of 6x4 full page

Explanation
-----
All info below was found in DHL's API doc from the following YAML file

https://developer.dhl.com/sites/default/files/2026-05/dpdhl-express-api-3.3.0.yaml

There are 2 issues with the current implementation regarding the label format.

1. The formats defined on the model (the `ProviderDHL` `delivery.carrier`) do not match the ones of the API. From the API, the accepted values are the following:

- ECOM26_84_A4_001
- ECOM26_84_001
- ECOM_TC_A4
- ECOM26_A6_002
- ECOM26_84CI_001
- ECOM26_84CI_002
- ECOM26_84CI_003
- ECOM_A4_RU_002
- ECOM26_84_LBBX_001
- ECOM26_64_LBBX_001

(values taken from the excerpt below)

```
templateName:
    description: >-
      Please enter DHL Express document template name.
      <BR>                Sample Transport label
      templates:<BR>                ECOM26_84_A4_001
      <BR>                ECOM26_84_001 - default<BR>
      ECOM_TC_A4<BR>                ECOM26_A6_002<BR>
      ECOM26_84CI_001<BR>                ECOM26_84CI_002 - supported
      single customer barcode<BR>                ECOM26_84CI_003 -
      to be used if customer barcodes are used<BR>
      ECOM_A4_RU_002<BR>
      ECOM26_84_LBBX_001 - supported for loose BBX shipment<BR>
      ECOM26_64_LBBX_001 - supported for loose BBX shipment<BR>
      [...]
    type: string
    maxLength: 25
    example: ECOM26_84_001
```

[...]: additional info unrelated to labels (useful only for other `typeCode` values)

Since `ProviderDHL` is a model, the `dhl_label_template` selection values cannot be changed and must thus be mapped to the corresponding API values.

- 8X4_A4_PDF => ECOM26_84_A4_001
- 8X4_thermal => ECOM26_84_001
- 8X4_A4_TC_PDF => ECOM_TC_A4
- 6X4_thermal => ECOM26_A6_002
- 6X4_A4_PDF => ECOM26_A6_002
- 8X4_CI_PDF => ECOM26_84CI_001
- 8X4_CI_thermal => ECOM26_84CI_001
- 8X4_RU_A4_PDF => ECOM_A4_RU_002
- 6X4_PDF => ECOM26_A6_002
- 8X4_PDF => ECOM26_84_001

Couple notes about this matching:
- There is no 6x4 in the API, so A6 is used instead (A6 is 105x148mm, 4x6 is   101.6x152.4mm so not a perfect match but the best option still)
- ECOM26_84_001 and ECOM26_A6_002 are used as default values for the respective   formats when there is no exact match possible (eg 6x4 only has one option in the API, the default one)
- "A4" is being ignored, because of point 2

2. There is a specific field to force the label to be in A4 format (according to the API, see excerpt below)

```
fitLabelsToA4:
  description: >-
    To print respective Transport Label and Waybill document into
    A4 margin PDF.<BR>                Note:
    ECOM26_A6_002,ECOM26_84CI_001,ECOM26_84CI_002,ARCH_6X4,ARCH_8X4
    template. <BR>                This option is applicable only
    for PDF encodingFormat selection.<BR>                false:
    Transport Label and Waybill document will use default margin
    settings (default behavior) <BR>                true:
    Transport Label and Waybill document will print into A4 margin
    PDF
  type: boolean
  example: false
```

-----
Ticket:
opw-6148713

Forward-Port-Of: odoo/enterprise#117281

Applying stock quants validation was performing poorly due to multiple bottlenecks in `Picking._check_entire_pack` and `StockMoveLine._apply_putaway_strategy`:

* **Redundant updates** were performed on `location_dest_id` in the move lines and the package levels (which internally update all related move lines too), even when the location remained unchanged.
* The main loop inside `_check_entire_pack` was **O(N^2)** time relative to the number of move lines due to internal filtering logic.
* **Cache misses** triggered unnecessary SQL queries when retrieving `move_line_ids` from `package levels`, while they are already cached via the pickings and can be grouped by `package_level`.

---

### Benchmark
Benchmark conducted on a customer database with **400k** `stock_move_line` records within **800** `pickings`, testing performance of the action `StockQuant.action_validate` with different sizes of move lines. Each test was run multiple times and shown is the average mean, all with negligible variance.

| Metric | Before | After | Delta |
| :--- | :--- | :--- | :--- |
| **Benchmark (1k lines)** | 10.5s | 2.2s | -80% |
| **Benchmark (5k lines)** | 121s | 8.5s | -93% |
| **Benchmark (50k lines)** | 887s | 56s | -94% |
| **Benchmark (400k lines)** | timeout | 777s | (within time limit) |

**OPW-6045513**

Forward-Port-Of: odoo/odoo#262717
Forward-Port-Of: odoo/odoo#257829

**Problem:**
A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered.

**Steps to reproduce:**
1. Create a combo product bundling two storable items.
2. Sell the combo on a sale order, confirm and invoice it.
3. Deliver every combo item.
4. Open Accounting > Review > Invoiced Not Delivered.

**Current behavior:**
The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information.

**Expected behavior:**
The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered.

**Cause of the issue:**
A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where
`qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever.

**Fix:**
Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct.

opw-6215110

Forward-Port-Of: odoo/enterprise#118942

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

Forward-Port-Of: odoo/odoo#265378

<h2>Context</h2>

Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.

When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed, it tries to update the CoA by adding/updating accounts, using the accounts in the file `l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.

<h2>Problem</h2>

Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which tries to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled from True to False during the update of the CoA, while it still contains partially reconciled transactions.
<details>

<summary>Traceback</summary>

```
File "/home/odoo/src/odoo/19.0/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
    Template._load_data({'account.account': Template._get_account_account('pl')})
  File "/tmp/tmpm8z3nlb0/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5171, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1122, in _load_records_write
    super()._load_records_write(values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5092, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1045, in write
    self.filtered(lambda r: r.reconcile)._toggle_reconcile_to_false()
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 975, in _toggle_reconcile_to_false
    raise UserError(_('You cannot switch an account to prevent the reconciliation '
odoo.exceptions.UserError: You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending.
```

</details>

<h2>Solution</h2>

I have sanitized the dict `data` using the `_pre_reload_data` method, so that the traceback does not appear anymore when upgrading. 

<h3>Notes</h3>

`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.


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

Forward-Port-Of: odoo/odoo#257006