[master] Report 400 (Remittance Advice) Does Not Include Applied Vendor Refund Entries Resulting in Incorrect Total Calculation

[Fixes4BC (neeleshsinghal)]

No description provided.

[Copilot]

Pull request overview

This pull request fixes Report 400 “Remittance Advice - Entries” so vendor refund entries that share the payment’s Vendor No. + Document No. are surfaced as report lines and the printed total is adjusted so it reconciles with the rendered lines.

Changes:

• Extend the report’s marking logic to include Refund vendor ledger entries that share Vendor No. + Document No. with the selected payment.
• Skip payment-discount logic for refund lines and adjust the report total to account for refund line amounts.
• Add a new unit test scenario ensuring such refunds appear as lines on the report.

Reviewed changes

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

File	Description
src/Layers/W1/Tests/Report/RemittanceREPCheckUT.Codeunit.al	Adds a new UT covering the “refund shares payment doc no” scenario, plus helper to create payment/refund entries.
src/Layers/W1/BaseApp/Purchases/Reports/RemittanceAdviceEntries.Report.al	Updates Report 400 line selection and total/discount logic to include and correctly total refund entries.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style}$

The two new Labels EntryNoElementTok and DocTypeElementTok are declared inside the procedure-local var block of RefundSharingPaymentDocShownOnRemittanceAdviceEntries. That pattern is fragile for XLIFF extraction and translation-key stability; move both Labels to the codeunit's top-level var section and keep them Locked = true there.

Knowledge:

• microsoft/knowledge/style/labels-declared-at-object-scope.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.35.4}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new refund scenario only proves that a refund row appears and is typed as Refund, but the production change also adds refund-specific amount logic (LineDiscount clearing and Amount -= LineAmount in RemittanceAdviceEntries.Report.al). Add an assertion on the rendered amount element so the test fails if the refund row is shown with the wrong value even though it exists.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.35.4}

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept with Suggestions

What this PR does

This change makes Report 400 include vendor refund ledger entries that share the selected payment's vendor and document number, then skips payment-discount handling for those refund lines and adjusts the displayed total. The main report path now covers the reported refund line gap, and the added test checks that the refund line is printed. The core branch is narrow, but one copied remittance-advice path still uses the old allocation logic, and the new test does not assert the total that this fix is meant to reconcile.

Problem-solution fit

Fit: Partial

The reported bug is clear: a refund line is missing while the total includes it, so the printed details do not reconcile. The report dataset change addresses the visible report line, but it does not cover every path that builds remittance advice data from the same posted payment, and the regression test checks only line presence.

Suggestions

S1 (🟠 Moderate): Keep electronic remittance output aligned
The electronic remittance advice buffer still uses the old Report 400 allocation logic. Update that buffer path too, or electronic remittance advice created from the posted payment can still omit the refund line.

S2 (🟠 Moderate): Assert the reconciled amount in the test
The new test proves that the refund line is printed, but it does not prove that the line amount and total reconcile. Add assertions for the refund line amount and the report total so the -= LineAmount change is covered.

Risk assessment and necessity

Risk: Report 400 is a financial-facing report, so wrong lines or totals can be sent to vendors. The direct printed report path is low-risk and covered by a focused test, but the electronic remittance advice export path uses a copied buffer builder for posted payments and remains a regression surface.

Necessity: The change is needed because a refund that belongs to the same payment document must appear in the remittance details when it affects the total. The scope is mostly right for a bug fix, but it should include the copied remittance-advice builder and a total assertion to make the fix complete.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10796 round=1 by=alexei-dobriansky at=2026-08-31T06:14:29Z lastSha=9bc0943bf9f394419af29458921c4fef714834b2 reviewKey=6d31d9c99fec3eaa600ce9ee1e016a6192f04c8010630010b87a4032d6ae96bc suggestions=S1@41fb4617,S2@6891b160

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

In AddRemittanceAdviceLines, the amount-direction check at line 298 was updated to treat 'Applied Doc. Type' = Refund the same as Credit Memo ('if ... in ["Credit Memo", Refund] then CreditLineAmount'), but the sibling BillingReference check a few lines below (line 310, 'if LineBuffer."Applied Doc. Type" = LineBuffer."Applied Doc. Type"::"Credit Memo" then CreditNoteDocumentReference else InvoiceDocumentReference') was not updated to include Refund. As a result, a Refund line is now exported with CreditLineAmount but its BillingReference still falls into the 'else' branch and is emitted as an InvoiceDocumentReference, which is inconsistent with how Credit Memos (the other document type sharing the credit-amount treatment) are referenced. This asymmetry between two conditionals gated on the same enum value, changed in the same commit, is a likely oversight — verify the PEPPOL/UBL semantics for a refund's BillingReference and either add Refund to the CreditNoteDocumentReference branch or add an explicit comment clarifying why refunds intentionally use InvoiceDocumentReference.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.35.4}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new refund branch in Export Remit. Advice PEPPOL30 (treating Applied Doc. Type = Refund as a credit line) has no dedicated test coverage in this diff. The new report test (RefundSharingPaymentDocShownOnRemittanceAdviceEntries) exercises report 400 only; it does not validate the PEPPOL XML serializer output for refund-ledger entries, so this branch can regress silently. Add a focused AL test that builds a refund-applied remittance buffer and asserts the exported XML uses CreditLineAmount (and the correct BillingReference element) for a Refund applied-doc-type line.

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.35.4}

[alexei-dobriansky]

Good Sense Reviewer - Round 4

Recommendation: Request Changes

What this PR does

The latest commit changes the electronic remittance advice path so refund lines reduce the header total and are exported as credit lines. This addresses the previous amount-direction issue. The direct report path and its regression test still match the reported refund total scenario, but the new export branch leaves the billing reference on the invoice path for refund lines.

Status of previous suggestions

ID	Title	Status	Author response
S1	Keep electronic remittance output aligned	Addressed	No new reply. This was already addressed before this round.
S2	Assert the reconciled amount in the test	Addressed	No new reply. This was already addressed before this round.
S3	Sign refund amounts in the buffer	Addressed	No direct reply. The latest commit now subtracts refund amounts from TotalPaid and exports refunds as CreditLineAmount.

New observations (commits since round 3)

S4 (🔴 High): Keep refund references on the credit path
Refund lines now use CreditLineAmount, but the BillingReference branch below still sends refunds through InvoiceDocumentReference. Treat refunds like the other credit line there too. Otherwise the PEPPOL XML can describe a reducing refund line with the wrong referenced document type.

Risk assessment and necessity

Risk: Report 400 and electronic remittance advice are financial-facing. The amount direction is now corrected, but the PEPPOL export can still produce a refund line whose amount says credit while its billing reference says invoice, which can confuse recipients or imports.

Necessity: The change is still needed because refund lines that affect the payment total must appear in remittance details. The latest commit is narrow and fixes the prior total issue, but the XML reference branch needs to stay aligned with the new refund credit-line behavior before merge.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10796 round=4 by=alexei-dobriansky at=2026-09-01T12:23:51Z lastSha=7e43a1ea188b1ba984de65c7624ae5f9e68e2d15 reviewKey=b7acfb3a7247e2adcf9ae46d6cad0473b1f0df6747e4156751a34640bc75ca53 suggestions=S1@41fb4617:addressed,S2@6891b160:addressed,S3@2b5ff012:addressed,S4@d49a1921:new parentRound=3

[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.

[github-actions]

Could not find a linked work item. Please link one in either of these ways: (1) link an ADO work item using the pattern 'AB#' followed by the work item number - you may use the 'Fixes' keyword to automatically resolve it when the pull request is merged, e.g. 'Fixes AB#1234'; or (2) link a GitHub issue of type 'Task' using the pattern 'Fixes #' followed by the issue number, e.g. 'Fixes #1234'.