[Master]-]Withholding Tax Entries are not generated at payment because the Withholding Tax. Prod. Posting Group field gets not transferred to the payment line

[neeleshsinghal]

AB#639524

[github-actions]

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

WHTProdPostGroupTravelsFromJournalLine is titled/commented as verifying that 'Withholding Tax Prod.

Post. Group travels from the applied invoice to the payment line' via the new AssignWHTPostingGroupOnCreatePayment subscriber (which only fires from the Create Payment page's OnBeforeUpdateGnlJnlLineDimensionsFromVendorPayment event). The test only creates and posts an Invoice and then asserts that the Withholding Tax Entry generated for that Invoice has the expected posting group -- it never creates a payment, never applies one to the invoice via 'Applies-to ID', and never drives the Create Payment page (or the buffer/event it publishes). The GenJournalLine array is declared as array[2] but only element [1] is ever used, which is consistent with the payment leg being missing. As written, the test would pass even if AssignWHTPostingGroupOnCreatePayment were deleted or broken, so the new production behavior in WithholdingTaxJnlSubscriber.Codeunit.al ships without regression coverage. If this impact would otherwise be judged major (an entirely untested new code path), note it here rather than escalate severity: recommend extending the test to actually apply/post a payment line (or otherwise trigger OnBeforeUpdateGnlJnlLineDimensionsFromVendorPayment with a populated TempVendorPaymentBuffer) and assert the resulting Gen. Journal Line's 'Wthldg. Tax Prod. Post. Group'.

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

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

[github-actions]

Copilot PR Review

Iteration 2 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@186d8a131465475c79244d994acb872cd5c0d4bf

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Testing	1	0	1	1	0

Totals: 0 knowledge-backed · 1 agent findings.

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

• layer-disabled (knowledge) : 2 file(s)

_{Findings produced by the AL review agent v1.7.3. Reply 👎 on any inline comment to flag false positives.}

[github-actions]

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

The new event subscriber AssignWHTPostingGroupOnCreatePayment (WithholdingTaxJnlSubscriber.Codeunit.al) copies 'Wthldg.

Tax Prod. Post. Group' from the Withholding Tax Entry onto the Gen. Journal Line when a payment is created via the 'Create Payment' page. This is new production logic that changes financial posting data. The single test added in this PR (WithholdingTaxProductPostingGroupIsCopiedToWithholdingTaxEntry) only exercises direct invoice posting and asserts that the group is copied onto the Withholding Tax Entry - a pre-existing code path unrelated to the new subscriber. None of the existing 'Create Payment' related tests invoke the page's OnBeforeUpdateGnlJnlLineDimensionsFromVendorPayment event (they post payments directly through Gen. Journal Line, bypassing the page). As a result, the new subscriber's behavior - including its guard clauses (Applies-to ID blank, Vendor Ledg. Entry No. = 0, no matching Withholding Tax Entry) and the successful copy path - has no test coverage. Recommend adding a test that drives the 'Create Payment' page (or otherwise raises OnBeforeUpdateGnlJnlLineDimensionsFromVendorPayment) to verify the Gen. Journal Line's WHT Product Posting Group is populated correctly before posting.

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

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