The standard cron process reconciles batches of 100 bank statement lines at a time. In multi-company environments with large historical datasets, this query frequently timed out, exceeding the 15-minute execution limit. Even when throttled to a batch size of 10 records, the query required approximately 18.8 seconds to execute.

The performance degradation was driven by the following factors:

1. Suboptimal Lateral Filtering: The statement line batch array filter was placed inside the `LATERAL` block's `WHERE` clause. This prevented the query planner from optimizing the drive path effectively across iterations.
2. Inefficient Join Sequence and Filtering: The original join order scanned `account_move_line` before resolving the company hierarchy constraint. As a result, millions of rows across all companies were retrieved from the index, forcing repeated primary key lookups on `res_company` before ultimately discarding over 99.9% of the records via the late `parent_path` hierarchy filter.

This commit addresses these issues by:

1. Moving the `st_line.id` filtering constraint out of the lateral subquery and into the outer main query block to guide the execution path properly.
2. Reordering the inner `LATERAL` subquery to resolve the company hierarchy (`res_company`) prior to joining `account_move_line`. This constraints the scan boundaries early in the pipeline.

Performance Benchmarks (10 record batch):
- Before Execution Time: ~18,818 ms
- Before Shared Hit Blocks: 8,535,272
- After Execution Time: ~130 ms
- After Shared Hit Blocks: 67,204 ms

Before Plan: https://explain.dalibo.com/plan/h4739gh3519eaa43
After Plan: https://explain.dalibo.com/plan/5ebc5g8deff272gc

## Problem

When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation
logic.

This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted.

**Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly.

<img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" />

## Root Cause

The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was
either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render.

## Fix

- **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line.
- **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value.

## Steps to Reproduce (before fix)

1. Create an export invoice (e-Factura Exportación) for a foreign partner.
2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU.
3. Add a global discount of 648.00 (same amount) so the total is 0.00.
4. Confirm and send to Uruware — the CFE is rejected / discount block is missing.

## Verification

After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document.

Forward-Port-Of: odoo/enterprise#124910
Forward-Port-Of: odoo/enterprise#120130