**Description of the issue/feature this PR addresses:**

When a batch recompute of `vies_valid` contains both a parent (commercial) partner and a child sharing the same VAT, and the child happens to be iterated before its parent, the child ends up with `vies_valid=False` instead of the parent's real, freshly-checked value.

**Current behavior before PR:**

`_compute_vies_valid` loops over `self` in whatever order the batch happens to have:

```python
for partner in self:
    ...
    if partner.parent_id and partner.parent_id.vies_vat_to_check == partner.vies_vat_to_check:
        partner.vies_valid = partner.parent_id.vies_valid
        continue
    status = partner._check_vies_iap()
    partner._update_vies_status(status)
```

`Field.compute_value()` removes the whole batch from the "to compute" queue *before* running this loop (it does so upfront, in case the method does not assign every record). So when the loop reaches a child and reads `partner.parent_id.vies_valid` to reuse it, that field is no longer marked "to compute" for the parent, and reading it just returns whatever is currently cached/stored — which, if the parent has not been processed yet in this same loop, is still the old/default value. The child copies that stale value and, being a stored field, keeps it forever: nothing re-triggers its computation afterwards.

Example:
```python
parent = env['res.partner'].create({'name': 'Parent Co'})
child = env['res.partner'].create({'name': 'Child Address', 'parent_id': parent.id})
child.vat = 'BE0477472701'   # queues the child's compute first
parent.vat = 'BE0477472701'  # queues the parent's compute second
child.vies_valid   # False, even though the VAT is valid
parent.vies_valid  # True
```

**Desired behavior after PR is merged:**

Every partner without a parent is always computed before any child that may reuse its value, regardless of the batch's original order — so the child correctly ends up with the parent's real `vies_valid`.

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

**Issue**
The expiration date is left blank when generating serial/lot numbers on a sml in a receipt, instead of being set from the product's default expiration settings.

**Steps to reproduce**
- Create a product tracked by SN, with Inventory > Traceability > Expiration Date enabled and an expiration time set.
- Create and confirm a PO for that product.
- Go to the receipt, open the Detailed Operations popup, and use "Generate Serials/Lots". -> The expiration date is not set on the generated serial/lot.

**Cause**
While generating the serial number, `action_generate_lot_line_vals` is called: https://github.com/odoo/odoo/blob/5d5f5381c27f67a8655a1c18bf1802c877d4cae2/addons/stock/models/stock_move.py#L1008 But it makes no reference to `expiration_date`.

Moreover, it does not call `_compute_expiration_date` yet, before the save is performed: https://github.com/odoo/odoo/blob/5d5f5381c27f67a8655a1c18bf1802c877d4cae2/addons/product_expiry/models/stock_move_line.py#L38-L40

**Solution**
Backport the fix from 19.0: https://github.com/odoo/odoo/commit/4f339301179c93a8bd48c55e3c54923c4698861a

together with its follow-up, which avoids overwriting an expiration date already provided by a pasted import: https://github.com/odoo/odoo/commit/d0e0785c2fe63b6b7984432f5d0cdd73d4ca72ef

opw-6417108

## Bug n°1 (sale)

Downpayment lines don't appear on the final invoice, when there is a credit note linked to the downpayment, even if the resulting downpayment is not zero.

**STEP TO REPRODUCE**
1. Create a SO.
2. Create a downpayment (let's say 100$).
3. On this downpayment create a credit note, and set the downpayment line on the credit note to 50$.
4. Return to the SO, and create the final invoice.
5. On the final invoice, there is no mention of the downpayment and credit note.
Expected behavior:
The final invoice contains a downpayment line with a unit price of 100$ - 50$ = 50$.

**CAUSE**
We invoice the downpayment line 1 time for the downpayment, and 1 time for the credit note.
This make qty_to_invoice computed on the downpayment line equal to 0, so it's skipped in the final invoice.

**FIX**
For downpayment line, we ignore the qty_to_invoice, and check if the price_unit of the downpayment line is not 0.
If so, we should invoice the downpayment line.
For final invoice, the invoiced qty should be -1, and 1 for downpayments and downpayment credit notes.

## Bug n°2 (l10n_fr_pdp)

Odoo doesn't correcly handle downpayments when sending invoices using pdp.
1. Because of bug n°1, since downpayment lines don't appear on the final invoice when there is a credit note on the downpayment, the downpayment lines also don't appear in the generated xml.
2. For downpayment, the InvoiceTypeCode should be 386. For credit note of downpayment, the CreditNoteTypeCode should be 503.
For the final invoice (invoice done after downpayments), the ProfileID should be B4.
3. On the final invoice, their should be BillingReference for each downpayments and credit note of those downpayments. With a corresponding DocumentTypeCode (386 downpayments, 503 credit notes).

On import, there is 2 cases to handles for the final invoice.
1st case: the downpayments lines are present in the final invoice. (already handled by default)
2nd case: the downpayments line are not present in the final invoice. The downpayment amount is in the prepaidAmount node, and all amounts on the xml correspond to
the invoice without any downpayments.
In the 2nd case, we need to find the downpayments, and copy their lines to the final invoice.

**STEP TO REPRODUCE**
1. Create a sale order.
2. Create a downpayment.
3. Create the final invoice and send it via pdp.
5. Inspect the xml and notice the requirements stated previously are not met.

opw-6420924

Behavior before:
Stamping payment complements fails with PAC validation error CRP20274 when partial payments reconcile across invoices with multi-decimal unit prices.

Behavior after:
Payment CFDI XML generates and stamps successfully. Summary tax fields (ImporteP / BaseP) automatically align with the sum of child lines (ImporteDR / BaseDR), satisfying SAT validation rules without affecting financial ledgers.

Root Cause:
Invoice lines derived from dynamic pricelists, tax-inclusive pricing, or currency conversions store unit prices as 14-decimal floating-point numbers in account_move_line.price_unit (e.g., 38.19628647214854).

During _l10n_mx_edi_add_payment_cfdi_values:

1. Child Document Lines (TrasladoDR): Odoo computes line tax amounts, applies percentage paid, and rounds to 6 decimal places per line (171.708217 + 186.628646 = 358.336863).

2. Payment Summary Total (TrasladoP): Odoo sums unrounded 14-decimal floats across all lines first, then rounds to 6 decimals at the end (358.336864).

Because SAT rule CRP20274 requires ImporteP to equal sum of ImporteDR, this 0.000001 floating-point drift triggers a hard rejection.

Fix:
In _l10n_mx_edi_add_payment_cfdi_values(), added an explicit check that calculates the sum of pre-rounded child line values (dr_base_sum / dr_importe_sum). If a sub-cent discrepancy (< 0.01) exists between the summary total and the child line sum, p_tax['base'] and p_tax['importe'] are overridden to equal the exact sum of child lines.

Steps to Reproduce:
1. Create a customer invoice where unit prices carry extended decimal precision (e.g., 38.19628647214854 from tax-inclusive pricing or 6-decimal pricelists) with multi-tax rules applied (IVA 16% + IEPS 30%).
2. Create a second similar PPD invoice for the same customer.
3. Register a single partial payment that reconciles across both invoices.
4. Attempt to process/generate the Payment CFDI XML.
5. Observe error CRP20274 (or CRP20273 for BaseP) returned by the PAC validator.

opw-6480236