[IRS Forms] Performance optimization

[dcenic]

What & why

What

In codeunit 10041 "IRS 1099 Form Box Calc. Impl.":

FindRelatedApplicationDetailedVendorLedgerEntries: changed SetCurrentKey from ("Vendor Ledger Entry No.", "Entry Type") to ("Application No.", "Vendor No.", "Entry Type") (existing Key10).
FilterPaymentVendorLedgerEntries: added a VendorNo parameter and applies SetRange("Vendor No.", VendorNo) when a specific vendor is requested.
No schema changes — both keys already exist on Detailed Vendor Ledg. Entry. No new keys/SIFT.

Why

Vendor form-box calculation walks every payment/refund in the period and, for each application, queries related application detailed ledger entries. Profiling showed a single query (FindRelatedApplicationDetailedVendorLedgerEntries) accounting for ~86% of a ~10-minute run (~167k executions). Its old current key forced an ORDER BY "Vendor Ledger Entry No.", whose only predicate was a non-sargable <> — so SQL scanned in that order and filtered the selective equality predicates (Application No., Vendor No., Entry Type) as residuals. Aligning the current key with those equality filters lets the optimizer satisfy the ordering with a selective index seek instead of a broad scan. The added vendor filter stops single-vendor recalculations from enumerating the whole period's payments. Runtime was constant regardless of form count because the cost is driven by payment/application history, not the number of forms — this addresses that root cause.

Linked work

Fixes AB#647491

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Existing IRS1099FormCalcTests cover the affected paths (multi-application aggregation and single-vendor-among-others); calculation output is unchanged since aggregation is order-independent. Perf win to be confirmed by re-profiling / query plan

Risk & compatibility

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This Bug PR optimizes IRS 1099 form-box calculation in codeunit 10041 by filtering payment and refund vendor ledger entries by vendor when a vendor is requested, and by using the existing Detailed Vendor Ledg. Entry Key10 for related application entries. The vendor filter is equivalent to the old per-entry guard but avoids reading unrelated vendors, and the blank-vendor path still processes all vendors. The new current key exists in BaseApp and is also used by BaseApp application/unapplication code for application-number flows, while the existing filters still keep the same vendor, transaction, application, and entry-type result set.

Suggestions

No suggestions.

Risk assessment and necessity

Risk: The regression surface is limited to US IRS 1099 form-box calculation and IRIS/vendor overview callers that use the same calculation facade. The change does not alter public signatures, schema, events, amounts, or posting logic; the main risk is query-plan behavior, and the functional filters remain the same.

Necessity: The linked Bug 647491 and PR description describe a concrete performance problem in a high-volume calculation path. The scope is narrow and uses an existing BaseApp key instead of adding schema, so the change is justified for the reported scenario.

---

[AI-PR-REVIEW] version=1 promptVersion=2 system=github pr=10509 round=1 by=alexei-dobriansky at=2026-08-21T13:10:15Z lastSha=cb05b4778c0b012d57c5591d112d1169dccd3869 reviewKey=bea5a9e808463617e53d12d07f5e613e57bd2b0a7073d56a3d7b863581cddc85 suggestions=