Currently, an error occurs when the user clicks on the translate button.

**Steps to Reproduce:**

 - Install the `CRM` module.
 - Go to `settings` and in `Languages` add 1 more language.
 - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`.
 - Click `New` and, in the `Name` field click the `translate button` on the right.

**Behavior in 18.0**

When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, 
the translation dialog shows the translated value on the second click.

**Behavior in saas-19.1**

`AssertionError: Invalid falsy real id`

Error:
After this [recent commit], when the user clicks on the translate button, if the record has a 
root record, the root record is saved before opening the translation dialog. However, in the 
case of an editable DynamicList view, the record does not have a root record so saving 
the record returns a promise instead of the resolved value [1].
Because of this promise, the condition fails [2], and the translation dialog is opened with a 
falsy ID since the record is not yet saved [3]. 
In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f).

This commit ensures that await is used so the resolved value is returned after the record is 
saved before opening the translation dialog.

[recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be

[1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23

[2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26

[3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41

sentry-7384270487

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

Forward-Port-Of: odoo/odoo#267914

### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number

While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice

DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check

Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>SETP990001021</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432

### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number

opw-6164321

Forward-Port-Of: odoo/enterprise#118319

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

Forward-Port-Of: odoo/odoo#264435
Forward-Port-Of: odoo/odoo#259384

Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle.

Steps to reproduce:
-------------------
* Open shop
* Make an order using the customer account for a customer, don't invoice it
* Refund one of the order using the customer account, don't invoice it
* Make a new order using the customer account
* In the customer list, find the customer used and select "Settle Orders"
> The 2 orders are present in the list

Why the fix:
------------
Originally the list would only show the orders for chich the customers have due (>0).
https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8

But recently the code we also see the refunds in the list as well.
https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0.

So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal.
* Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer.
* Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s)
and invoice them, either settling the order but that means that now there's money deposited on the customer account.

Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either.

Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out.

We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle.

opw-6170830

Forward-Port-Of: odoo/enterprise#117725

## Steps to reproduce:
- Install the `quality_mrp` module.
- Create a new product.
- Create a Quality Point with: 
  Type: Measure,
  Control per: Product/Operation
  Operations: Manufacturing
- Create and confirm MO for the product.
- Update the Quality Point: 
  Remove the 'manufacturing' operation type and add 'receipts' type. 
  Change Control per to 'Quantity'.
- Open the MO and start a quality check.
- Enter an invalid measure and try to validate it.

## Error:
`AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'`

## Cause:
Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error.

## Fix:
This commit uses the first lot/serial from the MO.
Note: Multiple produced lots are only possible for serial-tracked products.

sentry-7511513479

Forward-Port-Of: odoo/enterprise#119231

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#268128
Forward-Port-Of: odoo/odoo#266917

**Steps to reproduce:**

- Setup a Verifactu installation and a Spanish company
- Go to the PoS, make a Sale
- Keep the ticket
- Go to the /pos/ticket URL and enter the ticket informations
- Last step also works when requesting an invoice in the backend on the order
- Go to the order in the backend, an error is shown, the cancellation didn't go through
**Veri*Factu documents can only be generated for paid or posted Point of Sale Orders.**

**Why the fix:**

When we directly invoice an order, we do not go through the verification of being paid and done. This is why is works, but when making the invoice after the sale is done, we cancel the order first, then we register the invoice instead. When trying to cancel the order, we check if the order is either paid or done, but it is currently invoiced as we just generated the invoice.

We now allow no errors if the order is in the invoiced state, and let it pass through.
With this flow we get the same result as the direct invoice from the PoS.

The new cancellation on the order  and submission on the invoice may take a bit of time to get accepted but they will be eventually.

opw-6139200

Forward-Port-Of: odoo/odoo#267869
Forward-Port-Of: odoo/odoo#264272

Issue:
Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobilira CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button).

opw-5432421

Forward-Port-Of: odoo/enterprise#119244
Forward-Port-Of: odoo/enterprise#108355

Currently, it's possible to experience very slow loading speed of the partner list and/or browser crashes in the POS when there are thousands of customers stored in the browser cache.

This appears to be caused by a few reasons compounding together:

1. While we limit the number of customers in the initial render of the list, there is no limit during the search. Therefore, if there are thousands of customers matching the search pattern loaded in the browser cache, the browser will attempt to render equally as many `PartnerLine` components.
2. A 100 ms debounce time is fast enough to trigger the render after each key stroke. 200~300ms is the industry standard for Software UI debounce.
3. For each customer rendered in the list, we may perform a search for its parent partner amongst all loaded customers with the function `PosStore.getPartnerCredit()`.

This PR aims at reducing the number of partner lines rendered in a short period of time and thus, at improving speed and avoiding crashes.

Steps to reproduce:
1. Create a fresh db + install the point_of_sale with demo data
2. Populate the res.partner model by a factor of 100 to reach 4000+ partners
3. Update the following system parameter to make sure that we load all partners in the browser cache when we open the POS session:
    - `point_of_sale.limited_customer_count` -> 5000
4. Open a POS session and and click on the `Customer` button to render the partner list
5. Type `adm` in the search bar at normal typing speed
6. Crash

Ticket: opw-5435973

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

Forward-Port-Of: odoo/odoo#258667

Backport of https://github.com/odoo/odoo/pull/267790

Before this commit, when loading discuss app initially with demo data, sometimes there was a crash from maximum stack.

This happens due to infinite loop in discuss store with field `livechats`, which as a computed inverse `appAsLivechat`:

- Initially the field `livechats` has 2 conversations `[1, 2]`
- When adding conversation `3`, the `appAsLivechat` auto-computes to add this conversation to `livechats`, which triggers these field commands:

1. `appAsLivechat`: `[["REPLACE", 3]]`
2. `livechats`: `[["ADD.noinv", DiscussApp]]`

This is fine by itself, but somehow the `"ADD.noinv"` triggers a `[["DELETE.noinv", 1]]` on the inverse field `appAsLivechat`, which is then turned by the versioning system into a `[["REPLACE", [3]]]`, which in turn does a `[["DELETE.noinv", 1]]` and so on infinitely.

The `"DELETE.noinv"` is turned into `"REPLACE"` by the versioning of fields, which is ok, but it does it mistakenly with only considering new field `[3]` rather than having also `[1, 2]` that was there before. The history lacks `[1, 2]` so that's why it can't `"REPLACE"` with these values, even though the saved data already has them, but then the store is aware of deletion of these records, hence the infinite loop.

The underlying issue is that live chats `[1, 2]` were added in store without any track in history. This comes from some internal operations on record lists that apply related change on inverse, but this is done immediately with `.add()` or `.delete()` which doesn't reach the tracking of history of field version in `updateFields()`.

This commit fixes the issue by converting the `[inverse].add()` and `[inverse].delete()` into `updateFields()`, so that this is the same operation but it makes it tracked by the field version history.

Task-6073452

### [FIX] website: prevent inserting block snippet with powerbox in inlines

Inserting block snippet with powerbox when the selection is inside an editable part limited to an element that can only contain inline nodes leads to invalid html (like `<div>` inside `<span>`).

This commit disables insertion of block snippets when the selection is such a part of the document.

Steps to reproduce:
- Open website builder
- Put cursor in "copyright" at the bottom of the footer
- Type `/alert` and press enter
- Bug: `<div>` element is inserted inside `<span>`, that is invalid html

task-6259092

### [FIX] website: prevent unwrapping `s_blockquote` on insert with powerbox

When the snippet `s_blockquote` was inserted with the powerbox or pasted from clipboard in an unbreakable element which does not allow blocks as children, the `<blockquote>` element itself was abandonned and its children were inserted instead. This lead to insertion of a broken snippet.

This commit marks the `s_blockquote` snippet as "unsplittable" so that always stays in one piece when inserted.

Steps to reproduce:
- Open website builder
- Put cursor in a link
- Type `/blockquote` and press enter
- Bug: the snippet's children are inserted, instead of snippet itself

task-6259092

Forward-Port-Of: odoo/odoo#267111

**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#268351
Forward-Port-Of: odoo/odoo#265811