## **Issue:**
When creating an upsell after a subscription is invoiced, the qty_invoiced
field on the sale order line was showing 0.0, even though related invoice lines
existed.

## **Steps to reproduce:**
- Create and confirm a subscription.
- Update the subscription `next_invoice_date` to a future date.
- Generate an invoice for the subscription.
- Create an upsell order from the subscription.
- Confirm and invoice the upsell order.
- Open the upsell sale order and check qty_invoiced.

## **Before Fix:**
In _compute_qty_invoiced(), upsell lines have recurring_invoice=True and
order_id.state='sale', so they are processed by
_get_subscription_qty_invoiced(). The deferred date filter excludes their AMLs
because of this condition,
https://github.com/odoo/enterprise/blob/2ed34cc902d148fba7a88c159cd5c67a62112865/sale_subscription/models/sale_order_line.py#L189
returning 0.0 in the result dict. Since recurring_invoice=True, upsell lines
never reach other_lines and super()._compute_qty_invoiced() is never called,
causing qty_invoiced to fallback to its default value 0.0.

After Fix 1 routes upsell lines to super()._compute_qty_invoiced(), a
second issue is revealed. The _get_invoice_lines() overridden and applies
a line.date > last_invoice_date filter. Since this condition
fails and returns an empty recordset, leaving qty_invoiced at 0.0.

## **After Fix:**
1. In _compute_qty_invoiced(), upsell lines are routed to other_lines to
bypass  _get_subscription_qty_invoiced() and delegate to
super()._compute_qty_invoiced().

2. In _get_invoice_lines(), upsell lines are excluded from the date-based
filtering and letting upsell lines use the base _get_invoice_lines method.

OPW - 6213551

Steps to reproduce : [Video](https://drive.google.com/file/d/1px4J2oZJUtfBwIA_syQfdgXfRRg_6EBg/view?usp=drive_link)

OPW - 6213551

The _get_putaway_location() method tries to determine a location in which a product can be stored:

https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/product_strategy.py#L175-L181

When no location can be used, the loop iterates over the whole list
to call _get_weight() method on each one.

We propose to batch the call to _get_weight() method for all locations
that will be used and store the result in a dictionnary passed in the context
to avoid computing them several times during the same delivery preparation.

Benchmarks
--------------

For one product with no possible location:

| No locations | Before PR | After PR |
|------------|--------|-------|
|       780  |    9 s  |   < 1 s |

For 98 products that can be placed in various locations:

| No locations | Before PR | After PR |
|------------|--------|-------|
|       6000  |    20 s |    8 s |

For one product that could be placed in any of the indicated locations, we will compute the weights for every location while only the first one would have been computed without the fix:

| No locations | Before PR | After PR |
|--------------|-----------|----------|
|          500 |     41 ms |   524 ms |
|         2000 |     97 ms |   2.02 s |
|        10000 |    513 ms |  10.83 s |

opw-5949370

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

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

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

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

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

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

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