Steps to reproduce:
- Install the `l10n_es_reports` module and switch to the `ES company`.
- Go to Invoices and create an invoice with taxes, then confirm it.
- Navigate to Accounting > Reporting > Tax Report.
- From the smart button, select `Report: Tax Report (Mod 390) (ES)` and 
  choose the year as `This Financial Year`.
- Download the `BOE` file using the dropdown and fill the wizard fields 
  (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345).
- Upload the generated .txt file to the AEAT portal. (AEAT credentials are required)

**Observation:**
AEAT rejects the file with:
`Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'`

**Root cause:**
At [1], when `judicial_person_procuration_date` is `false`, an empty string is 
written to the BOE file, resulting in blank spaces in the exported file. This 
does not comply with AEAT’s required numeric format and causes the file 
to be rejected.

**Fix:**
This commit ensures the file contains '00000000' when 
`judicial_person_procuration_date` is false, complying 
with AEAT numeric format requirements.

[1]:
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696

opw-5995290

Forward-Port-Of: odoo/enterprise#109652

The bank reconciliation view was freezing on large databases (50k+ invoices,
90k+ journal entries), making it impossible to expand lines, filter, or interact
with the view in any way. Attempting to open a line would sometimes result in a
timeout.

**Root cause:** The `reconciledLineName` getter was called multiple times per
render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL
re-evaluates the template on every reactive state change, this created an O(n×m)
computation loop (n renders × m statement lines) that overwhelmed the browser.

**Fix:** Cache the result in OWL reactive state via a dedicated
`_computeReconciledLineName()` method, called once on setup and reactively via
`useEffect` when `line_ids.records` changes. The template is updated to store
`Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding
the array on every iteration.

| Metric | Before | After |
|---|---|---|
| Longest blocking task | 15 091 ms | 5 118 ms |
| Total blocking time | 74 147 ms | 22 481 ms |
| Avg. click response | 2 163 ms | 28 ms |
| Max click response | 14 305 ms | 222 ms |
| Total microtasks executed | 9 917 | 32 484 |

opw-5879798

Forward-Port-Of: odoo/enterprise#107135

[FIX] documents_account: sync all XML documents for account moves

Before this commit, the synchronization between accounting attachments and
the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol).

This caused several specific issues:
1. When creating an invoice via the Accounting upload interface, only the
   generated PDF was synced to the correct Documents folder, leaving the
   original XML file unsynced.
2. When creating an invoice from an existing file in the Documents app
   (via server action), the system correctly synced the generated PDF,
   but failed to move or sync the original XML source file to the
   target folder.
3. When receiving vendor bills via Peppol or other EDI networks, the proxy
   attaches the fetched XML to the `account.move` via an `ir.attachment` 
   write. Because this bypassed the existing sync filters, the Peppol XMLs 
   were never pushed to the Documents app.

This commit updates the `ir.attachment` logic in both `create` and `write`.
It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`)
is attached to an `account.move`—regardless of the move type or whether it 
was uploaded manually or fetched via EDI—the document synchronization logic 
is triggered, properly linking and filing the XML alongside the PDF.

Task-5909245
Task-5917535

Forward-Port-Of: odoo/enterprise#106574

PR #212726 removed a Many2One field and used an existing binary field, `l10n_it_edi_attachment_file`, to store E-invoice files as XMLs. This change was made for security reasons.

However, this PR also stores attachments embedded in the `<Allegati>` element of the XML in this same field. This results in three issues when importing invoices from the SDI:

1. The first embedded attachment will overwrite the XML file's contents, corrupting it.
2. Subsequent embedded attachments will continue to overwrite the previous attachment.
3. All embedded attachments are linked to the `account.move` record by the Many2one field `attachment_ids`, which is contrary to the stated goal of PR #212726.

These behaviors cannot be replicated in a runbot environment, as there is no way to test the SDI import process in runbot at the time of writing.

Localhost environments can replicate this issue by receiving an XML from the test l10n_it API server, or by passing similarly encrypted data to the method `_l10n_it_edi_process_downloads()`. See the method `test_decrypt_invoice_from_IAP()` from PR #250439 for an example of the encryption process.

**Solution**: Do not overwrite the field `l10n_it_edi_attachment_file`. Add stored field(s) to master for attachment(s) within an XML's `<<Allegati>` element.

This PR also improves how Allegati attachments are named, as my previous PR #246220 could result in files with two extensions (e.g. "filename.txt.TXT").

Ticket [link](https://www.odoo.com/odoo/project.task/5800658)
opw-5800658

Forward-Port-Of: odoo/odoo#252806

Case 1:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment > down payment of 300 is created in SO.
- In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order.

**Issue:**
- The down payment line is added twice in the POS order.

**Root cause:**
- At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order.
- At [2], the down payment line from the SO is added again.
- Here, when `Automatic invoice` is on and we make the online payment
  then `amount_paid` is updated and the downpayment invoice is also created.
- So, we have also downpayment line in sale order also.

**Solution:**
- Ensure that if a downpayment line has already been added to the POS order,
  the first downpayment line matching `amount_paid` is skipped.

[1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93
[2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111

Before:
<img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" />


After:
<img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" />

Case 2:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
-The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice
  is automatically created and amount_paid is also updated.
- At [3], the logic subtracts both the total invoice amount and amount_paid from
  the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to
  an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is
  encountered again, it should be skipped to avoid double-counting.

[3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

Forward-Port-Of: odoo/odoo#255420
Forward-Port-Of: odoo/odoo#242026

# How to reproduce
- Go to the Pysical Invetory list view
- Select more than one record
- In the Counted field, try to type a two digit number

# The problem
A popup asking for confirmation for editing a field is shown before the user has the time to type in the other digits. This makes it so it is not possible to input a number that has more than one digit.

# Cause
The Counted (invetory_quantity) field in the list view uses a special widget (CountedQuantityWidgetField). This widget has the responsability to set the inventory_quantity_set field to true when the the value of the inventory_quantity field is updated.

The inventory_quantity_set field is updated on input :
https://github.com/odoo/odoo/blob/f450bb6379b5c0354c048abcc688428d8bff1172/addons/stock/static/src/widgets/counted_quantity_widget.js#L33-L35

The inventory_quantity field is updated on blur :
https://github.com/odoo/odoo/blob/f450bb6379b5c0354c048abcc688428d8bff1172/addons/stock/static/src/widgets/counted_quantity_widget.js#L44-L49

This does not make a lot of sense, because we tell the backend that the quantity has been changed before sending the new quantity. This was not really an issue before but starting in 19.0, this commit (https://github.com/odoo/odoo/commit/9f0470b48e4e8c783513788e269ad16cbf84b7af) made the Physical Invetory list view multi-editable, highlighting the desynchronization

This fix aims to resynchronize the editing of both of theses values, allowing the bulk edit at the same time.

opw-5908205

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

Forward-Port-Of: odoo/odoo#254399

Steps to reproduce:
- Go to Azure Interior contact form:
  - Sales & Purchase tab > Group RFQs > Always
- Create a storable product "P1":
  - Route: Resupply Subcontractor
  - BoM:
    - Type: Subcontracting
    - Component: C1 with Dropship route and azure interior as vendor
- Create a storable product "P2":
  - Route: Resupply Subcontractor
  - BoM:
    - Type: Subcontracting
    - Component: C2 with Dropship route and azure interior as vendor
- Create a purchase order with one unit of P1 and P2
- Confirm the purchase order

Problem:
Two RFQs are generated (one for C1 and one for C2) instead of a single grouped RFQ.

When confirming the purchase order, a stock reference is created and assigned to it. This reference is correctly propagated to the picking and stock moves.

However, when the two manufacturing orders are created, new stock references are generated instead of reusing the original one. As a result, each MO ends up with a different reference:

https://github.com/odoo/odoo/blob/2713876dbc70d3984e584a9037a2206dcda4e84a/addons/mrp_subcontracting/models/stock_picking.py#L69-L72

This prevents from grouping RFQs, since the grouping logic relies on identical references. When the first RFQ is created for C1, it uses the MO reference, and when searching for a candidate RFQ for C2, none is found due to the reference mismatch:
https://github.com/odoo/odoo/commit/77dc92e4a0db0575a1a0e865cdd0c82978d593f6#diff-201f9fd7ec1067f7530aafeaa88420021930be82ce89e912d595ed55bb885f26R370-R372

Solution:
Reuse existing stock references when creating subcontracting MOs instead of creating new ones.

opw-5895378

Forward-Port-Of: odoo/odoo#254327

When creating a backorder because of missing product, if there is an extra product received it will create a return also create a return for that product.

### Steps to reproduce:

* Create and confirm a purchase ordre for 2 products (A & B)
* Add a product C to the picking order and reduce the quantity of product B received
* Validate the picking ordre
* Create a backorder
* Go back on the PO and open the linked pickings 
-> There is delivery linked for product C

### Observation:

When processing the backorder, it will sync the delivery and the PO with _action_synch_order where it will add the new product to the PO: https://github.com/odoo/odoo/blob/1a62c4333de61a4e1358ef8e229b2e0f5a3e9826/addons/purchase_stock/models/stock_move.py#L88-L89 
The create that is started by the creation of the new POL will trigger _create_or_update_picking that will create a stock move and a picking: https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L97 https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L197-L198

opw-5868172

Forward-Port-Of: odoo/odoo#248433

### Steps to reproduce:

- Ensure that sale_stock is installed
- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse WH2 and enable: Resupply from WH1
- Create a physical product using the route: Resupply from WH1
- Click on the product form cog wheel icon > Replenish
- Replenish 1 unit to warehouses 2
#### > The delivery that was created from WH1 to the inter company transit location does not set the `partner_id` (delivery address) to the partner of warehouse 2.

### Cause of the issue:

Triggering the replenish will create a move chain relying on the `_run_pull` mechanich. In particular,
the receipt move will be created first from Inter-company transit to `WH2/Stock` without `partner_id`:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_move.py#L1709 https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_move.py#L1674-L1677 Then, during its confirmation, the delivery move from WH1/Stock to the intercompany transit location will be created based on the rule and, thanks to these lines:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L342-L349
The `partner_id` of WH2 will be set as the `partner_id` of the delivery. Since there is a single partner this will also set the partner of the `move_values` of the delivery move we are creating to this partner:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L355-L360 However, if `sale_stock` is installed that `move_value` is reset to the value provided by the procurement values just a few lines bellow: https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L381-L384 because the `partner_id` field is part of the field name returned by the `_get_custom_move_fields`:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/stock.py#L173-L176
Since the `partner_id` value provided by the procurement values was `False`, it resets the the `partner_id` creation value to `False`.

### Fix:

As the flow relies on the value provided here:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_rule.py#L342-L349 when `sale_stock` is not installed but relies on the value of the procurement provided here:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_move.py#L1709 https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_move.py#L1674-L1677
if `sale_stock` is installed, it is necessary that both provide the same value to keep coherence in the flow. However, since the partner is will be expected to be set also via the procurement values, it is necessary to adapt the condition to which we will set a partner on the reception of the inter-company-transit:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_rule.py#L349 Which is the reason why we moved this line should be triggered only if no partner was set by the procurement values.

opw-6034309

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

Forward-Port-Of: odoo/odoo#254855

**Problem:**
When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment.

**Steps to reproduce:**
1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe.
2) Change the company currency to euro.
4) Create a manual invoice for that customer.
5) Pay the invoice using the pre-configured Stripe SEPA token.
6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending".
7) When Stripe confirms the transaction, the payment stays canceled.

**Cause:**
In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled.

**Solution:**
- Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process.

opw-5934381

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

Forward-Port-Of: odoo/odoo#253876