[Main]-Incident 21000001049308 : [BC-IN] Purchase invoice with a deferral schedule and Non-availment GST is not functioning correctly

[v-ajaztabrez]

Bug 641225: Incident 21000001049308 : [BC-IN] Purchase invoice with a deferral schedule and Non-availment GST is not functioning correctly

AB#641225

Issue: A purchase invoice with Non-availment GST does not get posted when a Default Deferral Template is configured on the G/L Account Card.

Cause: The base application's CheckDeferralConditionForGenJournal validation in codeunit Deferral Utilities raises an error for the general journal line, which blocks the posting.

Solution: Subscribed to the OnBeforeCheckDeferralConditionForGenJournal event in codeunit Gen. Jnl.-Post Handler to handle this validation for the IN Localization in the Tax Engine application. This change also resolves the related Journal Voucher posting issue caused by the same validation.

[github-actions]

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

The new subscriber to Deferral Utilities.OnBeforeCheckDeferralConditionForGenJournal unconditionally sets IsHandled := true with no guard.

This event fires from the Gen. Journal Line 'Deferral Code' OnValidate trigger for every journal line in every journal template (General, Purchases, Sales, etc.) across all companies with the IN localization installed, not only for the specific Purchase-invoice-with-Non-availment-GST scenario the fix targets. As written, it permanently disables the base validation that prevents a Deferral Code from being used together with a Gen. Journal Template whose Source Code does not match Source Code Setup, for every IN journal line, indefinitely. That validation exists to catch a real misconfiguration (mismatched Source Codes on deferral-enabled journals), so this removes a genuine safeguard well beyond the bug's scope. Note: because of the material breadth of this behavior change, the underlying impact is closer to major/blocker than the capped 'minor' severity assigned here per agent-finding policy; consider promoting this to a knowledge-backed rule if the pattern recurs.

Recommendation:

• scope the bypass to the actual failing condition (for example, check the GST classification / Non-Availment flag on the line, or another discriminator specific to the reported scenario) before setting IsHandled := true, so unrelated journal entries still get the Source Code validation.

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

[v-ajaztabrez]

It's ok for this case

[github-actions]

Copilot PR Review

Iteration 2 · Outcome: completed

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

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
Agent	1	0	1	1	0

Totals: 0 knowledge-backed · 1 agent findings.

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

[v-ajaztabrez]

Closing it to requeue checks and tests.

[github-actions]

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

The new event subscriber OnBeforeCheckDeferralConditionForGenJournal unconditionally sets IsHandled := true, which disables the base application's CheckDeferralConditionForGenJournal validation (Gen.

Journal Line source-code/deferral consistency check) for every Gen. Journal Line processed once this app is installed, not only for the Non-Availment GST + deferral scenario the PR description says it fixes. Every other IsHandled-setting subscriber in this same codeunit (e.g. OnBeforePurchaseUseCaseHandleEvent) guards the assignment with a condition such as PurchLine.GetSkipTaxCalculation(); this new subscriber has no such guard. As written, the fix silently removes a legitimate business validation (the Source Code Setup / Gen. Journal Template consistency check) for all general journal lines with a deferral code, including scenarios unrelated to the reported bug, which could let inconsistent journal templates post without the intended error. Note: because this disables a base validation gate unconditionally and globally, the real-world impact is closer to major/blocker; severity is capped here per the agent-finding policy.

Recommendation:

• scope the bypass to the specific Non-Availment GST/deferral condition described in the bug (e.g. check the relevant tax/GST attributes on GenJournalLine or the source document) before setting IsHandled := true, mirroring the guarded pattern used elsewhere in this codeunit.

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