[main] - Incorrect Prepayment Invoice Amount for Sales Orders with Invoice Discount, Prices Including VAT and negative non-inventory line.

[v-ankitgoyal]

Fixes : AB#643210
Issue :- Incorrect Prepayment Invoice Amount for Sales Orders with Invoice Discount, Prices Including VAT and a negative non-inventory line (regression). The posted prepayment invoice is lower than the sum of the lines' "Prepmt. Line Amount".

Root cause :-
The UpdateDifferenceAmount correction (added for work item 612821) derived the expected prepayment from the header: SalesHeader.Amount * SalesHeader."Prepayment %". SalesHeader.Amount includes negative and non-prepayment lines, and the single header Prepayment % does not reflect per-line prepayment, so the base is too low. The valid prepayment is then misread as a rounding difference and subtracted from the last buffer line, understating the invoice.

Solutions :-
Compute the expected prepayment amount line by line from the actual prepayment lines, using each line's own Amount and Prepayment %, so negative/non-prepayment lines are excluded and mixed percentages are respected. The correction still only fires on a genuine rounding surplus.

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept with Suggestions

What this PR does

Fixes an incorrect prepayment invoice amount on Sales Orders that combine invoice discount, "Prices Including VAT", and a negative non-inventory line with 0% prepayment. The old code computed expected prepayment as SalesHeader.Amount * SalesHeader."Prepayment %" — but SalesHeader.Amount includes non-prepayment negative lines, causing a valid buffer total to be misidentified as a rounding surplus and subtracted.

The fix replaces the header-based calculation with a line-by-line sum using ApplyFilter(SalesHeader, 2, SalesLine) (Statistic filter: "Prepmt. Line Amount" <> 0), which correctly excludes lines with 0% prepayment. Rounding is applied once at the end using Currency."Amount Rounding Precision". The approach is sound: it uses each line's own Amount * "Prepayment %", avoiding cross-contamination from non-prepayment lines and respecting mixed prepayment percentages. The NA layer correctly preserves the "Prepmt. Include Tax" branch using "Amount Including VAT". Purchase prepayments do not have the UpdateDifferenceAmount logic, so no symmetry fix is needed.

Suggestions

S1 - Guard still requires header Prepayment % <> 0
The UpdateDifferenceAmount procedure is gated by SalesHeader."Prepayment %" <> 0. If a user sets per-line prepayment percentages without setting a header percentage, this guard skips the correction entirely. This is pre-existing behavior not introduced by this PR, but worth noting: a future order with per-line-only prepayment and invoice discount could still accumulate a rounding surplus without correction. No action required now.

S2 - Test uses only 100% prepayment — add a partial-prepayment variant
The new test covers 100% prepayment exclusively. A partial prepayment (e.g., 50%) with the same scenario would exercise the SalesLine.Amount * SalesLine."Prepayment %" / 100 arithmetic where per-line rounding matters more. Consider adding a second test case with "Prepayment %" := 50 and two VAT rates to strengthen coverage.

S3 - Test helper GetSalesPrepaymentLineAmount uses FindSalesLine, not ApplyFilter
The test helper GetSalesPrepaymentLineAmount iterates all sales lines and multiplies by "Prepayment %". Lines with 0% contribute zero, so the result is correct. However, if a line had a non-zero prepayment percentage but zero "Prepmt. Line Amount" (edge case with invoice discount reducing it to zero), the test would assert a different value than the production code. Minor robustness gap.

Risk assessment and necessity

Risk: Low regression risk. The change only affects UpdateDifferenceAmount, which fires only when HasInvoiceDiscount AND "Prepayment %" <> 0. The new CalcPrepmtAmount reads the same lines the buffer was built from (via ApplyFilter with Statistic option), so the expected amount now matches the buffer's own source. No public API or event signature changes. Performance: one additional FindSet loop over prepayment lines — negligible on typical orders.

Necessity: High. Without this fix, any Sales Order combining invoice discount + negative non-prepayment line posts a prepayment invoice with an amount lower than the lines' "Prepmt. Line Amount" sum. This leads to under-collection of prepayment, incorrect G/L entries, and potential reconciliation failures on the final invoice. No viable workaround exists except removing the negative line or disabling invoice discount.

---

[AI-PR-REVIEW] version=1 system=github pr=9656 round=1 by=alexei-dobriansky at=2026-08-03T09:42:00Z lastSha=4f37fe6be34514678c6c01b6eeb93ce708ee2335 suggestions=S1,S2,S3

[alexei-dobriansky]

Agentic PR Review - Round 2

Recommendation: Accept

What this PR does

This round adds one new test (SalesPrepmtInvoiceWithPartialPrepaymentAndTwoVATRates) covering 50% prepayment with two different VAT rates, and refactors the GetSalesPrepaymentLineAmount test helper to use ApplyFilter instead of iterating all sales lines. The production-side change adds SetLoadFields(Amount, "Prepayment %") before the FindSet loop in CalcPrepmtAmount, which is a correct performance improvement — ApplyFilter only sets filters, so the SetLoadFields call before FindSet is valid. Both test improvements directly address suggestions from round 1.

Status of previous suggestions

ID	Title	Status	Author response
S1	Guard still requires header Prepayment % <> 0	Not addressed	Informational note; round 1 explicitly said "no action required now". No change needed.
S2	Test uses only 100% prepayment — add a partial-prepayment variant	Addressed	New test with 50% prepayment and two VAT rates added in commit 81d1966.
S3	Test helper GetSalesPrepaymentLineAmount uses FindSalesLine, not ApplyFilter	Addressed	Helper refactored to use ApplyFilter with FindSet guard in commit 81d1966.

New observations (commits since round 1)

None — changes only addressed prior suggestions.

Risk assessment and necessity

Risk: The SetLoadFields addition is a safe read optimization with no behavioral effect; it narrows the fields loaded per iteration. The test helper refactor aligns test logic with production logic, which reduces the chance of future test drift. No new regression surface introduced.

Necessity: Unchanged from round 1. The fix is targeted and the new tests meaningfully strengthen coverage of the corrected calculation path.

---

[AI-PR-REVIEW] version=1 promptVersion=1 system=github pr=9656 round=2 by=alexei-dobriansky at=2026-08-07T11:43:20Z lastSha=487a3f493c7cfcbb883fcb7fd243d42fba1b95b2 reviewKey=f991372041afa89a3e1b64c131127d8c9d05496be4e3a2633da6306fe18e8f99 suggestions=S1@f0292ef0:notaddressed,S2@aa522cb0:addressed,S3@0d07f849:addressed parentRound=1