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

Steps to reproduce:

- Create a database in saas-18.3 or above.
- Install mrp_workorder.
- Create a storable product tracked by serial number.
- Either purchase the product from a vendor (a Partners/Vendors quant with negative quantity will be generated) or confirm a Manufacturing Order (a Production quant with negative quantity will be generated).
- Create a Manufacturing Order using this product as a component.
- In the Shop Floor, scan the serial number barcode to add the component.
- Check the location of the scanned component.

Issue:
-  When scanning a barcode in the Shop Floor,  searches for a quant matching the serial number with no location filter. Because of this, it returns whichever quant has the lowest database ID — which is the Partners/Vendors quant created during the vendor receipt (quantity = -1), instead of the correct WH/Stock quant (quantity = +1).

Solution:
- To resolve this issue, a location filter ( source location) and have been added to the quant search. As a result, always returns the correct quant from the move's source location with positive stock.

opw-5974474

**Steps to reproduce:**
- Open the PoS
- Select a combo and choose whatever
- Use the numpad or keyboard to set the combo's qty to 10
- Choose another customer or preset
- The price is all wrong

**Why the fix:**
Whenever we change the customer or the preset, the **setPriceList** function is triggered. In this
function we recompute the combo's children lines' price.

Before this commit, we assumed that the combo's parent line's qty would always be one, and the logic was written on this assumption. Meaning that when it's manually changed, the data is wrong. What really happens is that most of the children line's qty end up being treated as an extra price.

This happens because in our exemple, the parent and children lines have a qty of 10, but we only set the free qty based on the assumption that the parent line has a qty of 1 on those lines https://github.com/odoo/odoo/blob/f5d5783b6a0c908127aa620ad0ec5b0008d7adf4/addons/point_of_sale/static/src/app/models/pos_order.js#L482-L485

This means that, as the free qty is rapidly depleted, we fall back on the extra products, and their unit price end up becoming the combo's base_price.

We now set the right amount in the free qty based on the parent line's qty.

When doing this, another problem arises, we have to multiply the children's unit price by the parent's qty, as theunit price's computation was based on the fact that weonly have a qty of one on the parent line.
This is because we were still basing the unit_price the the parent's lstPrice, but this price was not using the parent's qty at all, so we need to multiply it by the parent line's qty to make it work.

The unit price handling has to be done in the **computeComboItems** function, as we also need to adjust the remaining price accordingly. An access to the parent's qty was added onto the child line, to avoid adding a default parameter to the function, which should be avoided in stable if possible.


opw-5266483

Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed.

The slowdown comes from `mrp.bom.line._get_cost_share()`, which is called for every line during a BoM explosion. When no explicit `cost_share` is set, the method recomputes the list of eligible BoM lines and checks whether any of them has a manual cost share.

That computation depends only on the BoM and the product variant, but it is recomputed for every exploded line during `mrp.bom.explode()`. This causes a full BoM scan to be repeated for every single line.

This commit introduces a contextual cache, initialized in `mrp.bom.explode()`, to store that metadata. We compute it once and reuse it for all lines of the same (BoM, variant) within the same explosion.

### Benchmark:

| BoM lines | Before PR | After PR |
| --- | ---: | ---: |
| 100 | 3.747s | 1.094s |
| 300 | 26.554s | 2.826s |
| 600 | 85.378s | 5.299s |
| 992 | 229.246s | 9.068s |

opw-6017626

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

Forward-Port-Of: odoo/odoo#254868

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