### Description of the issue/feature this PR addresses:
**Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor.

**Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records.

### Current behavior before PR: 
When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback.

### Desired behavior after PR is merged: 
The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected.

opw-6174628

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

Forward-Port-Of: odoo/odoo#266224

**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

Why this commit:
---

There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format.

Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency.

Starting from version 17.0, cash in/out receipts and the sales report use the local device time format.

This commit updates those references and aligns them with the Odoo-configured date format. 
During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69).
As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. 

After this commit:
---

<img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" />


All date references consistently use the Odoo-configured date format.

OPW: 6087341





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

Forward-Port-Of: odoo/odoo#266770
Forward-Port-Of: odoo/odoo#259112

**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

Currently, an error occurs when a user sets a non-numeric value as the journal's next check number.

**Steps to Reproduce:**
 - Install the `account_check_printing` module with demo data.
 - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`.
 - Open the `bank journal`.
 - In the `Outgoing Payments` tab > Enable `Manual Numbering`.
 - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`.

`ValueError: invalid literal for int() with base 10: 'FA1234'`

After [this commit], the next check number is converted to an integer without first validating that it 
contains only numeric characters [1]. Since the value can be non-numeric, converting it directly 
to an integer raises the error.

This commit ensures that the next check number is converted to an integer only after verifying 
that it contains numeric characters only.

[this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4

[1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61

sentry-7498755988

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

Forward-Port-Of: odoo/odoo#266280

Steps to reproduce:
===================
1. Edit a page, add a Cover/Banner block.
2. Set its background to a video, paste an Instagram URL
3. Save and open the published page.

=> Instagram embed is broken (iframe shows nothing / error).

Cause:
=======
Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render.

The unconditional append is itself a regression from the public-widget → interaction refactor in [2].
The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram.

Solution:
=========
remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction

[1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492
[2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4

opw-6233081

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

Forward-Port-Of: odoo/odoo#267016

**Steps to reproduce:**
- Install Accounting and l10n_ro_edi
- Switch to a Romanian localization (e.g. RO Company)
- Configure Romanian E-Factura

- Create an invoice with a product having a name longer than 100 chars
- Confirm the invoice
- Send E-Factura to SPV
- Fetch E-Factura status

**Issue:**
The invoice is rejected with the following error:
"[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100."

**Similar issue with the product description:**
"[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200."

**Similar issue with the note (i.e. Terms and Conditions):**
"[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300."

**Solution:**
Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300.

opw-5964904




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

Forward-Port-Of: odoo/odoo#267850
Forward-Port-Of: odoo/odoo#265811

Scenario:

- paste "język việt" (polish + vietnamese) in a page
- change website font to not be "Noto Sans", for example: Raleway
- open the page on Edge Browser on Android

Result: polish and vietnamese characters are using different font and
are visually different than latin character.

Cause: google fonts is serving for nearly all browsers font
configuration with woff2 files and unicode-range so the user only loads
the part of the font that will be used on the website. For Edge browser
on android, based on the user-agent chrome is serving only a TTF file
without unicode-range because it is thinking that unicode-range is not
supported. These files only contain basic latin characters, so extended
latin and vietnamese characters are being rendered with fallback "Odoo
Unicode Support Noto" that has a different weight and style for the same
weight.

Fix:

For the browser not supporting unicode-range (desktop edge before 2020,
Edge on android, …), in addition to latin we ask google fonts to
provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if
available. For other subset (hebrew, arabic, cyrillic, …) the intent is
to fallback on "Odoo Unicode Support Noto" since they should usually not
be mixed with latin characters.

Note: Edge on android in reality support unicode range, so this would be
solved if google fonts just served the unicode range font configuration
for that user-agent.

[1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets

opw-4642242

Forward-Port-Of: odoo/odoo#267798

When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it would raise with the following error message:
> The recipient bank account linked to this invoice is archived.
So you cannot confirm the invoice.

The state of the 'active_test' ctx key cannot be known in advance in a compute and should not be assumed as True; according to the framework team:
> In practice, a compute method cannot expect active_test to have
> a particular value. It may be invoked with any context. There is no
> "context purge" done by the ORM. The computation may be "prepared"
> with a context (the one of modified()) and actually done with another
> context (code accessing the field before some explicit flush). In
> other words, if the compute method searches for a record that matches
> some conditions, and if that record cannot be inactive, then this
> condition must be explicit in the search domain (or in the context).

opw-6229286

Forward-Port-Of: odoo/odoo#267398

**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