[Master]-Take Payment Discounts setting does not work as expected in the Suggest Vendor Payments EB routine from the EB Payment Journal in the Belgian version. by neeleshsinghal · Pull Request #9092 · microsoft/BCApps

neeleshsinghal · 2026-07-04T10:18:47Z

Workitem:- Bug 641379: [master] [All-e]Take Payment Discounts setting does not work as expected in the Suggest Vendor Payments EB routine from the EB Payment Journal in the Belgian version.

Fixes AB#641379

github-actions · 2026-07-04T11:47:37Z

                DueDate := WorkDate();
-            if PmtDiscDueDate = 0D then
-                PmtDiscDueDate := WorkDate();
+            if (IncPmtDiscount) and (PmtDiscDueDate = 0D) then


$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Report 2000019 declares SaveValues = true, so IncPmtDiscount and PmtDiscDueDate are meant to persist across invocations.

The new OnOpenPage logic is if (IncPmtDiscount) and (PmtDiscDueDate = 0D) then PmtDiscDueDate := WorkDate() else PmtDiscDueDate := 0D;. When the checkbox was previously saved as true together with a non-zero discount date (the normal steady state after a first run), reopening the request page evaluates the second condition to false (PmtDiscDueDate <> 0D) and falls into the else branch, which wipes the persisted date back to 0D on every subsequent open. This defeats SaveValues for this field and also risks tripping the existing OnPreDataItem check if IncPmtDiscount and (PmtDiscDueDate < Today) then Confirm(...)/Error(...) on every run, since 0D < Today is always true. Actual impact is functionally significant (silent loss of a persisted user setting plus a spurious confirm/error each run), which would normally warrant major severity, but this is flagged as an unbacked agent finding and capped at minor per BCQuality's agent-finding rules; consider promoting this to a knowledge-backed rule. Recommended

Recommendation:

only default the date when it is currently blank, independent of clearing on uncheck, e.g. keep if PmtDiscDueDate = 0D then PmtDiscDueDate := WorkDate(); in OnOpenPage (mirroring DueDate/PostingDate) and confine the clear-on-uncheck behavior to the checkbox's own OnValidate trigger.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

github-actions · 2026-07-04T11:47:38Z

Copilot PR Review

Iteration 11 · Outcome: completed

PR is a small, well-scoped bug fix (Suggest Vendor Payments EB: gate 'Pmt. Discount Date' on 'Take Payment Discounts') plus matching regression tests. No sub-skill found a knowledge-backed or high-confidence agent-level defect above the precision bar.

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Orchestrator pre-filter (13 file(s) excluded)

layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}

github-actions · 2026-07-05T05:58:01Z

+
+                        trigger OnValidate()
+                        begin
+                            if (IncPmtDiscount) and (PmtDiscDueDate = 0D) then


$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 2}}$

In the IncPmtDiscount field's OnValidate trigger, the new logic 'if (IncPmtDiscount) and (PmtDiscDueDate = 0D) then PmtDiscDueDate := WorkDate() else PmtDiscDueDate := 0D' resets PmtDiscDueDate to 0D whenever IncPmtDiscount is true but PmtDiscDueDate already holds a non-zero value (the else branch fires because the AND condition requires PmtDiscDueDate = 0D).

The prior code only ever initialized an empty date and never clobbered an already-set one. Recommend nesting the checks so a non-zero date is preserved when the checkbox is enabled, and only cleared when it is disabled: guard the WorkDate() default inside 'if IncPmtDiscount then' and only assign 0D in the 'else' for IncPmtDiscount = false.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

if IncPmtDiscount then begin if PmtDiscDueDate = 0D then PmtDiscDueDate := WorkDate(); end else PmtDiscDueDate := 0D;

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

…t-Discounts-not-work-in-EB-Payment-Journal

alexei-dobriansky · 2026-07-06T08:04:56Z

Agentic PR Review - Round 1

Recommendation: Request Changes

What this PR does

This PR makes the BE Suggest Vendor Payments EB request page clear Payment Discount Date when Take Payment Discounts is off, and adds regression tests for both toggle values. The direction matches the W1 intent: future invoices should only be selected for payment discount when the payment-discount option is enabled, and the discount date must drive the amount calculation. However, the new condition also clears a nonblank discount date when the option is enabled, so saved or custom dates can still make the report ignore the discount.

Suggestions

S1 - Keep discount date when enabled
The new if IncPmtDiscount and PmtDiscDueDate = 0D then ... else PmtDiscDueDate := 0D clears a nonblank PmtDiscDueDate even when IncPmtDiscount is true. Change it so the date is only cleared when IncPmtDiscount is false, and only defaulted to WorkDate() when the option is true and the date is blank.

S2 - Test discount-only selection and amount
The new false-case test uses a due date three months ahead, so the invoice is selected as a due invoice even without the payment discount path. Add a case where the invoice due date is after DueDate but the payment discount date is within the discount window, and assert no line when the option is false and the exact discounted amount when true.

Risk assessment and necessity

Risk: This is BE payment proposal logic, so the risk is financial: a wrong branch can suggest invoices at the wrong amount or with the wrong payment discount. No new BaseApp event publisher is involved, but the relevant BE unit-test check is currently failing, so the added coverage has not proved the change yet.

Necessity: The work item is a Bug with clear repro steps. Without a fix, the EB routine can use Payment Discount Date even when Take Payment Discounts is off, which can create confusing or wrong vendor payment suggestions.

[AI-PR-REVIEW] version=1 system=github pr=9092 round=1 by=alexei-dobriansky at=2026-07-06 lastSha=86ec162a21758c0488da8ec2ad598f1c2fe026f8 suggestions=S1,S2

alexei-dobriansky · 2026-07-06T08:29:57Z

Please review S1.

…t-Discounts-not-work-in-EB-Payment-Journal

github-actions · 2026-07-06T11:18:11Z

+        PaymentJournalLine.FindFirst();
+
+        // [THEN] Verify that the "Pmt. Discount Date" is Blank, Pmt Discount is not taken, in Payment Journal Line.
+        Assert.AreEqual(0D, PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date"));


$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 4}}$

WrongPmtDiscErr declares Comment = '%1 = Field Caption', but the two call sites pass the raw field value (a Date/Decimal) instead of FieldCaption(...).

On assertion failure the message reads 'Wrong 01/20/24 on the payment journal line.' instead of naming the field, contradicting the label's own documented placeholder contract and defeating its purpose for debugging.

Recommendation:

substitute PaymentJournalLine.FieldCaption("Pmt. Discount Date") / FieldCaption("Pmt. Disc. Possible") instead of the value.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

Assert.AreEqual(0D, PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine.FieldCaption("Pmt. Discount Date"))); Assert.AreEqual(0, PaymentJournalLine."Pmt. Disc. Possible", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine.FieldCaption("Pmt. Disc. Possible")));

Knowledge:

microsoft/knowledge/style/label-comment-explains-placeholders.md

microsoft/knowledge/style/fieldcaption-not-fieldname-in-user-messages.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

github-actions · 2026-07-06T11:32:52Z

+        LettersTxt: Label 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', Locked = true;
        WrongNumberOfLinesErr: Label 'Wrong number of  Payment Journal Lines.';
-        WrongStatusOfLineErr: Label 'Wrong status of Payment Journal Line.';
+        WrongPmtDiscErr: Label 'Wrong %1 on the payment journal line.', Comment = '%1 = Field Caption';


$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 4}}$

WrongPmtDiscErr is declared with Comment = '%1 = Field Caption', but none of its 4 call sites pass a FieldCaption — they all pass the field's actual value instead (e.g.

StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date")). On assertion failure this renders as a nonsensical message like 'Wrong 07/06/26 on the payment journal line.' instead of naming the field that was wrong. Pass PaymentJournalLine.FieldCaption("Pmt. Discount Date") / FieldCaption("Pmt. Disc. Possible") to match the documented Comment.

Knowledge:

microsoft/knowledge/style/label-comment-explains-placeholders.md

microsoft/knowledge/style/fieldcaption-not-fieldname-in-user-messages.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

alexei-dobriansky · 2026-07-06T14:39:32Z

Agentic PR Review - Round 2

Recommendation: Request Changes

What this PR does

Since round 1, the report logic was changed so Take Payment Discounts keeps a nonblank Payment Discount Date when the option is enabled, defaults it only when it is blank, and clears it when the option is disabled. This addresses the date-clearing bug in both the field validation and page-open paths. The tests were not changed in the new commit, so the discount-only selection and exact discounted amount gap remains.

Status of previous suggestions

ID	Title	Status	Author response
S1	Keep discount date when enabled	Addressed	No direct reply. Fixed in `src/Layers/BE/BaseApp/Local/BankMgt/Payment/SuggestVendorPaymentsEB.Report.al` lines 125-129 and 164-168.
S2	Test discount-only selection and amount	Not addressed	No direct reply. No test changed since round 1; the current tests still set `DueDate` three months ahead and do not add a discount-only selection case (`src/Layers/BE/Tests/Local/ERMPaymentJournal.Codeunit.al` lines 641-706 and 1628-1632).

New observations (commits since round 1)

None - the new commit only addresses S1 and does not introduce a new issue.

Risk assessment and necessity

Risk: This is BE payment proposal logic. A wrong branch can suggest invoices at the wrong amount or with the wrong payment discount. The round-2 code change is narrow, but the remaining test gap is still in financial logic.

Necessity: The bug is valid and the fix is needed. Without it, invoices eligible for payment discount can be suggested even when Take Payment Discounts is off, or discounts can be missed when the date is not kept correctly.

[AI-PR-REVIEW] version=1 system=github pr=9092 round=2 by=alexei-dobriansky at=2026-07-06 lastSha=546d30921ae710da0bdd1cdb9b64da3d1beaf371 suggestions=S1:addressed,S2:notaddressed parentRound=1

github-actions · 2026-07-07T04:06:05Z

+
+        // [THEN] Verify that the "Pmt. Discount Date" and Pmt Discount is taken, in Payment Journal Line.
+        Assert.AreEqual(WorkDate(), PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date"));
+        Assert.AreEqual(PaymentJournalLine."Pmt. Disc. Possible", Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));


$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 5}}$

Assert.AreEqual(PaymentJournalLine."Pmt.

Disc. Possible", Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), ...) at line 705 places the actual/recorded value first and the expected/computed value second, reversed from the (Expected, Actual) convention used by the other three Assert.AreEqual calls added in this same test (lines 669, 670, 704). Assert.AreEqual is symmetric for pass/fail, but the standard Assert library renders failures as 'Expected: Actual: ', so a failure here would report the recorded line value as 'Expected' and the freshly computed value as 'Actual' — backwards during triage. Recommend swapping the two arguments to match the surrounding convention.

Suggested change

Assert.AreEqual(PaymentJournalLine."Pmt. Disc. Possible", Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));

Assert.AreEqual(Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), PaymentJournalLine."Pmt. Disc. Possible", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

…t-Discounts-not-work-in-EB-Payment-Journal

…in-EB-Payment-Journal' of https://github.com/neeleshsinghal/BCApps into bugs/Bug-641379-Master-Take-Payment-Discounts-not-work-in-EB-Payment-Journal

Copilot

Pull request overview

This PR fixes Belgian “Suggest Vendor Payments EB” request page behavior so that disabling Take Payment Discounts truly disables the payment-discount path (by clearing/locking the Payment Discount Date), and adds BE regression tests to validate the corrected behavior.

Changes:

Updated the request page so Payment Discount Date is editable only when Take Payment Discounts is enabled, and is cleared when disabled.
Adjusted request page initialization/validation so PmtDiscDueDate is only defaulted when payment discounts are enabled.
Added BE test scenarios covering “take discount off/on” and the “invoice not yet due but discount window applies” selection logic.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
src/Layers/BE/BaseApp/Local/BankMgt/Payment/SuggestVendorPaymentsEB.Report.al	Makes Payment Discount Date dependent on Take Payment Discounts (editable + cleared/defaulted consistently).
src/Layers/BE/Tests/Local/ERMPaymentJournal.Codeunit.al	Adds regression tests and request page handlers to validate discount-selection behavior for BE payment journals.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

+        Assert.AreEqual(0D, PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date"));
+        Assert.AreEqual(0, PaymentJournalLine."Pmt. Disc. Possible", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));


+        Assert.AreEqual(WorkDate(), PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date"));
+        Assert.AreEqual(PaymentJournalLine."Pmt. Disc. Possible", Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));


+    [Test]
+    [HandlerFunctions('SuggestVendorPaymentsTakeDiscRPH')]
+    procedure SuggestVendorPaymentsWithoutTakingPaymentDiscount()


+    [Test]
+    [HandlerFunctions('SuggestVendorPaymentsTakeDiscRPH')]
+    procedure SuggestVendorPaymentsTakingPaymentDiscount()


+    [Test]
+    [HandlerFunctions('SuggestVendorPaymentsPmtDiscDateRPH')]
+    procedure SuggestVendorPaymentsSelectsDiscountOnlyEntryWithDiscountedAmount()


+    [RequestPageHandler]
+    procedure SuggestVendorPaymentsTakeDiscRPH(var SuggestVendorPaymentsEB: TestRequestPage "Suggest Vendor Payments EB")
+    begin
+        SuggestVendorPaymentsEB.DueDate.SetValue(CalcDate('<3M>', WorkDate()));
+        SuggestVendorPaymentsEB.IncPmtDiscount.SetValue(LibraryVariableStorage.DequeueBoolean());
+        SuggestVendorPaymentsEB.OK().Invoke();
+    end;


+    [RequestPageHandler]
+    procedure SuggestVendorPaymentsPmtDiscDateRPH(var SuggestVendorPaymentsEB: TestRequestPage "Suggest Vendor Payments EB")
+    begin
+        SuggestVendorPaymentsEB.DueDate.SetValue(LibraryVariableStorage.DequeueDate());
+        SuggestVendorPaymentsEB.IncPmtDiscount.SetValue(LibraryVariableStorage.DequeueBoolean());
+        SuggestVendorPaymentsEB.OK().Invoke();
+    end;


…t-Discounts-not-work-in-EB-Payment-Journal

alexei-dobriansky · 2026-07-08T12:36:05Z

Agentic PR Review - Round 3

Recommendation: Request Changes

What this PR does

Since round 2, the only author-owned non-merge commit adds automation in the BE test app. The new test creates a vendor with payment-discount terms, posts a purchase invoice, runs Suggest Vendor Payments EB with Last Due Date set to the invoice payment-discount date, checks that no line is suggested when Take Payment Discounts is off, and checks the discounted amount when it is on. This exercises the fixed report path, but it still does not assert that the proposed line keeps the expected Payment Discount Date in the discount-only case.

Status of previous suggestions

ID	Title	Status	Author response
S1	Keep discount date when enabled	Addressed	No direct reply after round 2. No regression found in the product-code behavior that was already fixed.
S2	Test discount-only selection and amount	Not addressed	No direct reply after round 2. Commit `0822b78206` adds a real discount-only BE test and verifies the discounted amount, but it does not assert that `Payment Discount Date` is retained on the suggested payment line.

New observations (commits since round 2)

None - the remaining issue is the carry-forward S2 test gap, not a new S3 issue.

Risk assessment and necessity

Risk: This is BE vendor payment suggestion logic. The product-code change is narrow, but the scenario touches payment discounts, dates, and suggested payment amounts, so a weak regression test can let a financial regression return.

Necessity: The bug is valid and the fix is needed. Without it, invoices eligible only through payment discount can be suggested even when Take Payment Discounts is off, or can be suggested with the wrong discount behavior when it is on.

[AI-PR-REVIEW] version=1 system=github pr=9092 round=3 by=alexei-dobriansky at=2026-07-08 lastSha=344268f91c0570a5bf7dedd82400397d931db3ea suggestions=S1:addressed,S2:notaddressed parentRound=2

…in-EB-Payment-Journal' of https://github.com/neeleshsinghal/BCApps into bugs/Bug-641379-Master-Take-Payment-Discounts-not-work-in-EB-Payment-Journal

alexei-dobriansky · 2026-07-09T11:09:21Z

Agentic PR Review - Round 4

Recommendation: Accept

What this PR does

Since round 3, the only author-owned non-merge commit updates the BE test app. The discount-only test still verifies that no payment line is suggested when Take Payment Discounts is off, and it still verifies the exact discounted amount when the option is on. It now also asserts that the suggested payment line keeps Pmt. Discount Date = WorkDate(), which closes the remaining test gap from round 3.

Status of previous suggestions

ID	Title	Status	Author response
S1	Keep discount date when enabled	Addressed	No direct reply after round 3. Product code was unchanged since round 3, so the previously addressed behavior did not regress.
S2	Test discount-only selection and amount	Addressed	No direct reply after round 3. Commit `ff2d91e088` extends `SuggestVendorPaymentsSelectsDiscountOnlyEntryWithDiscountedAmount` to assert `Pmt. Discount Date = WorkDate()` on the suggested line, and it still asserts the discounted amount.

New observations (commits since round 3)

None - the changes only strengthen the BE regression test and no new issue was found.

Risk assessment and necessity

Risk: The round-4 change is test-only. The covered behavior is still financially sensitive because it controls BE vendor payment suggestions, payment discount dates, and suggested payment amounts.

Necessity: The bug is valid and the fix is needed. Without it, invoices eligible through payment discount can be suggested when Take Payment Discounts is off, or can use the wrong discount behavior when it is on. The added assertions now cover both the discount date and amount for the discount-only path.

[AI-PR-REVIEW] version=1 system=github pr=9092 round=4 by=alexei-dobriansky at=2026-07-09 lastSha=37b5b3d5e728952f18d3d20705ec80454e3b1b04 suggestions=S1:addressed,S2:addressed parentRound=3

alexei-dobriansky · 2026-07-09T11:19:41Z

Very good, thank you!

neeleshsinghal · 2026-07-09T11:37:02Z

Very good, thank you!

@https://github.com/alexei-dobriansky
Thanks for suggestion

@ Could you also please approve this PR?

…t-Discounts-not-work-in-EB-Payment-Journal

Fix and automation

76c15b7

github-actions Bot added From Fork Pull request is coming from a fork Linked Issue is linked to a Azure Boards work item labels Jul 4, 2026

github-actions Bot added this to the Version 29.0 milestone Jul 4, 2026

neeleshsinghal added the Finance GitHub request for Finance area label Jul 4, 2026

neeleshsinghal marked this pull request as ready for review July 4, 2026 11:41

neeleshsinghal requested a review from a team July 4, 2026 11:41

github-actions Bot reviewed Jul 4, 2026

View reviewed changes

neeleshsinghal closed this Jul 5, 2026

neeleshsinghal reopened this Jul 5, 2026

github-actions Bot reviewed Jul 5, 2026

View reviewed changes

Merge branch 'microsoft:main' into bugs/Bug-641379-Master-Take-Paymen…

86ec162

…t-Discounts-not-work-in-EB-Payment-Journal

AndersLarsenMicrosoft previously approved these changes Jul 6, 2026

View reviewed changes

Merge branch 'microsoft:main' into bugs/Bug-641379-Master-Take-Paymen…

974f71d

…t-Discounts-not-work-in-EB-Payment-Journal

github-actions Bot reviewed Jul 6, 2026

View reviewed changes

Suggest Changes

546d309

neeleshsinghal dismissed AndersLarsenMicrosoft’s stale review via 546d309 July 6, 2026 11:25

github-actions Bot reviewed Jul 6, 2026

View reviewed changes

neeleshsinghal closed this Jul 7, 2026

neeleshsinghal reopened this Jul 7, 2026

github-actions Bot reviewed Jul 7, 2026

View reviewed changes

neeleshsinghal added 3 commits July 7, 2026 19:47

Merge branch 'microsoft:main' into bugs/Bug-641379-Master-Take-Paymen…

e50881d

…t-Discounts-not-work-in-EB-Payment-Journal

Add Automation

0822b78

Merge branch 'bugs/Bug-641379-Master-Take-Payment-Discounts-not-work-…

6c3bcca

…in-EB-Payment-Journal' of https://github.com/neeleshsinghal/BCApps into bugs/Bug-641379-Master-Take-Payment-Discounts-not-work-in-EB-Payment-Journal

neeleshsinghal requested a review from Copilot July 8, 2026 09:00

Copilot started reviewing on behalf of neeleshsinghal July 8, 2026 09:01 View session

Copilot AI reviewed Jul 8, 2026

View reviewed changes

neeleshsinghal enabled auto-merge July 8, 2026 09:10

Merge branch 'microsoft:main' into bugs/Bug-641379-Master-Take-Paymen…

344268f

…t-Discounts-not-work-in-EB-Payment-Journal

neeleshsinghal added 2 commits July 9, 2026 14:36

Round 3 Suggestion added

ff2d91e

Merge branch 'bugs/Bug-641379-Master-Take-Payment-Discounts-not-work-…

37b5b3d

…in-EB-Payment-Journal' of https://github.com/neeleshsinghal/BCApps into bugs/Bug-641379-Master-Take-Payment-Discounts-not-work-in-EB-Payment-Journal

neeleshsinghal added 2 commits July 9, 2026 18:53

Merge branch 'microsoft:main' into bugs/Bug-641379-Master-Take-Paymen…

3ac9555

…t-Discounts-not-work-in-EB-Payment-Journal

Merge branch 'microsoft:main' into bugs/Bug-641379-Master-Take-Paymen…

26dc865

…t-Discounts-not-work-in-EB-Payment-Journal

v-ankitgoyal approved these changes Jul 10, 2026

View reviewed changes

	Assert.AreEqual(PaymentJournalLine."Pmt. Disc. Possible", Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));
	Assert.AreEqual(Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), PaymentJournalLine."Pmt. Disc. Possible", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));

		Assert.AreEqual(0D, PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date"));
		Assert.AreEqual(0, PaymentJournalLine."Pmt. Disc. Possible", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));

		Assert.AreEqual(WorkDate(), PaymentJournalLine."Pmt. Discount Date", StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Discount Date"));
		Assert.AreEqual(PaymentJournalLine."Pmt. Disc. Possible", Abs(VendorLedgerEntry."Remaining Pmt. Disc. Possible"), StrSubstNo(WrongPmtDiscErr, PaymentJournalLine."Pmt. Disc. Possible"));

Uh oh!

Conversation

neeleshsinghal commented Jul 4, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot Jul 4, 2026

Choose a reason for hiding this comment

Report 2000019 declares SaveValues = true, so IncPmtDiscount and PmtDiscDueDate are meant to persist across invocations.

Uh oh!

github-actions Bot commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Copilot PR Review

Orchestrator pre-filter (13 file(s) excluded)

Uh oh!

github-actions Bot Jul 5, 2026

Choose a reason for hiding this comment

Uh oh!

alexei-dobriansky commented Jul 6, 2026

Agentic PR Review - Round 1

Recommendation: Request Changes

Uh oh!

alexei-dobriansky commented Jul 6, 2026

Uh oh!

github-actions Bot Jul 6, 2026

Choose a reason for hiding this comment

WrongPmtDiscErr declares Comment = '%1 = Field Caption', but the two call sites pass the raw field value (a Date/Decimal) instead of FieldCaption(...).

Uh oh!

github-actions Bot Jul 6, 2026

Choose a reason for hiding this comment

WrongPmtDiscErr is declared with Comment = '%1 = Field Caption', but none of its 4 call sites pass a FieldCaption — they all pass the field's actual value instead (e.g.

Uh oh!

alexei-dobriansky commented Jul 6, 2026

Agentic PR Review - Round 2

Recommendation: Request Changes

Uh oh!

github-actions Bot Jul 7, 2026

Choose a reason for hiding this comment

Assert.AreEqual(PaymentJournalLine."Pmt.

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

alexei-dobriansky commented Jul 8, 2026

Agentic PR Review - Round 3

Recommendation: Request Changes

Uh oh!

alexei-dobriansky commented Jul 9, 2026

Agentic PR Review - Round 4

Recommendation: Accept

Uh oh!

alexei-dobriansky commented Jul 9, 2026

Uh oh!

neeleshsinghal commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

neeleshsinghal commented Jul 4, 2026 •

edited by github-actions Bot

Loading

github-actions Bot commented Jul 4, 2026 •

edited

Loading

neeleshsinghal commented Jul 9, 2026 •

edited

Loading