[MAIN]-The system throws the error while posting a receipt against a Subcontracting Order.

[v-maheshsharma]

Bug 644092: Incident 51000001089716 : [BC-IN][28.1]The system throws the error while posting a receipt against a Subcontracting Order.

AB#644092

Issue:
Subcontracting receive/consume was failing with “Not enough inventory available at vendor location for this order” and showing incorrect remaining quantity in Apply Delivery Challan, especially when the same item had multiple variants.

Cause:
Remaining Quantity on Delivery Challan Line was aggregating inventory without enough granularity, so different variants/components were getting mixed. Also, in PostSubconComp, RemQtytoPost was not always reset after the last successful posting, which could trigger a false shortage error.

Solution:
Tightened the subcontracting inventory matching to be variant- and component-line-aware by refining the Delivery Challan Remaining Quantity flowfield and the ILE application logic. Also reset RemQtytoPost on final successful consumption so the shortage guard only fires for real shortages.

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

$\textbf{🟠\ High\ Severity\ —\ Breaking\ Changes}$

The shipped Delivery Challan Line.Remaining Quantity FlowField now adds Variant Code, Order No., Order Line No., and Prod. Order Comp. Line No. filters to its CalcFormula. This silently changes the value returned for existing rows and for any extension code that already calls CalcFields("Remaining Quantity") on this shipped, public field — including rows created before those discriminator fields were reliably populated (e.g., historical Delivery Challan Lines where Variant Code/Order No./Order Line No. were blank or differently sourced). Because this is a field on a published table used across the app (and potentially by partner extensions), changing its CalcFormula is a behavioral break, not a purely internal fix. Consider introducing a new field/version for the narrower semantics, or verify/backfill historical data so existing rows resolve identically before switching the existing field's formula.

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

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

The updated "Remaining Quantity" FlowField filters Item Ledger Entry by Variant Code, Order No., Order Line No., and Prod. Order Comp. Line No. (in addition to the existing filters), but no Item Ledger Entry key matches this full filter shape, and "Subcon Order No." is not indexed at all. On Delivery Challan pages/lookups this can turn CalcFields("Remaining Quantity") into an expensive residual-filter scan instead of an indexed SIFT lookup. Add or redesign an Item Ledger Entry key that matches the CalcFormula predicates, or reduce the FlowField to predicates already covered by an existing key.

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

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Error\ Handling}$

In PostSubcontractComponent's posting loop, ItemJnlPostLine.Run(ItemJnlLine) executes and commits inventory postings for each item ledger entry processed inside the repeat...until loop. The new check if RemQtytoPost <> 0 then Error(NotEnoughInvtoryErr); is placed AFTER this loop, meaning if the loop exhausts all available Item Ledger Entry records (ItemLedgerEntry.Next() = 0) without fully covering RemQtytoPost, one or more ItemJnlPostLine.Run calls will already have executed for the entries that WERE available before the error is raised. This design relies entirely on Business Central's implicit transaction rollback semantics (the whole call chain must be inside one uncommitted write transaction) to make this atomic; if any caller wraps only part of this in an explicit COMMIT, or if this method is ever invoked from a context with an intervening COMMIT, partial postings would persist while the overall operation reports failure to the user. Given this is new logic changing existing posting flow, verify no COMMIT occurs between the loop and this new Error() call in any call path, or move the insufficient-quantity check to precede any posting (e.g., pre-calculate total available remaining quantity across matched ledger entries before starting to post) to avoid relying on rollback-by-error for correctness.

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

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

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

[github-actions]

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

AppDelChallan."Applies-to Entry" already gives the full primary key for Item Ledger Entry, but the "Applies-to Entry" branch of GetApplicationLines still builds a filtered FindFirst() on a secondary key instead of a direct Get(). Use Get(...) first on the stored entry number, then validate the extra predicates (Variant Code, Open, Positive, Remaining Quantity) before falling back to the broader re-resolution path.

Knowledge:

• microsoft/knowledge/performance/use-get-instead-of-findfirst-on-full-primary-key.md

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

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

[github-actions]

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

CheckAvialibility() filters Delivery Challan Line by Variant Code after setting the current key to only "Delivery Challan No.", "Item No.", but this table declares no key that includes Variant Code. The lookup can read all rows for the challan/item pair and discard non-matching variants afterward; add or choose a key whose leading fields cover this access pattern.

Knowledge:

• microsoft/knowledge/performance/setcurrentkey-aligns-key-with-filters.md

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

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Breaking\ Changes}$

PostSubconComp and GetApplicationLines in SubcontractingPost.Codeunit.al are non-local posting helpers, so they are externally bindable contracts. This PR changes their behavior in place: PostSubconComp now throws a new NotEnoughInvtoryErr when residual quantity remains after posting (previously it could complete silently), and GetApplicationLines now narrows/re-resolves Item Ledger Entry selection with new Variant Code, Open, Positive, and Remaining Quantity > 0 filters. Dependent extensions that already call these helpers will observe a breaking behavioral change with no opt-in path. Either narrow these helpers to internal/local, or preserve prior behavior and introduce a separate, clearly-versioned entry point for the stricter logic.

Knowledge:

• microsoft/knowledge/breaking-changes/choose-access-modifiers-deliberately.md

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

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

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Request Changes

What this PR does

This PR makes India GST subcontracting receipt posting choose delivery challan and item ledger entries with more filters, mainly variant and production component information. It also resets RemQtytoPost when the last posting consumes the exact remaining quantity, then raises NotEnoughInvtoryErr if quantity is still left after the loop.

The reset of RemQtytoPost fixes a clear false-shortage path. The narrower ILE filters also match the reported multi-variant case better than the previous item-only matching. But the change is in posting and challan application logic, and two important gaps remain: there is no regression test for the multi-variant receipt scenario, and one lookup path still selects the first challan line by item and variant instead of the exact component line.

Suggestions

S1 - Add a multi-variant posting regression test
Add a test in the GST Subcontracting test app that creates the same subcontracting order item with multiple component variants, applies the delivery challan, and posts the receipt. This is posting code, and the existing test app already has helpers for subcontracting send, apply, receipt, and post flows.

S2 - Match the exact component line
CheckAvialibility() still finds Delivery Challan Line by delivery challan, item, and variant only. Add the component-line filters, or use the exact selected challan line, so two lines with the same item and variant cannot choose the wrong Applies-to Entry.

S3 - Verify the FlowField compatibility impact
Changing Delivery Challan Line.Remaining Quantity adds new filters to a shipped FlowField. Verify that existing delivery challan and item ledger rows have those discriminator fields populated, or add upgrade/backfill handling before relying on the narrower formula.

Risk assessment and necessity

Risk: This is high-risk because it changes subcontracting receipt posting, item ledger application, and a FlowField used by delivery challan pages and validation. A wrong match can consume from the wrong variant or component line, and a false shortage can block receipt posting. No BaseApp publisher dependency was found in this diff; the change is local to the IN GST Subcontracting app.

Necessity: The customer incident is important, and the work item type is Bug. Without a fix, subcontracting receipt/consume can fail with “Not enough inventory available at vendor location for this order” when variants are mixed. The scope is mostly targeted, but it needs exact component-line matching and a regression test before merge.

---

[AI-PR-REVIEW] version=1 system=github pr=9729 round=1 by=alexei-dobriansky at=2026-08-03T10:19:41Z lastSha=fb4e06fd9ae0b7f711b80330ec83b391945caae8 suggestions=S1,S2,S3

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

The shipped FlowField "Delivery Challan Line"."Remaining Quantity" (field 57) now adds Variant Code, Order No., Order Line No., and Prod. Order Comp. Line No. filters to its CalcFormula, so existing extensions, reports, and pages reading this field will get smaller totals for the same historical records than before this change. Consider preserving the old field semantics and introducing a new field for the narrower calculation, or explicitly documenting/versioning this as a behavioral change for consumers.

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

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

"Delivery Challan Line"."Remaining Quantity" now identifies inventory by Order No., Order Line No., and Prod. Order Comp. Line No., but the repeated Item Ledger Entry lookups in "Applied Delivery Challan" (the OnLookup trigger and the three near-identical helper procedures around lines 282-370) still stop at order line + item + variant, without the component-line filter. When the same item/variant appears on multiple production components within one order line, FindFirst() can persist "Applies-to Entry" from the wrong component, undercounting one challan line while consuming/returning against another. Add the component-line filter consistently to every one of these duplicated lookup blocks, ideally through one shared helper so the FlowField and the manual lookups cannot drift again.

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

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

In the "Applies-to Entry" OnLookup trigger (and the similarly-patterned procedures below it in the same file), the PR adds "Variant Code" as a new Item Ledger Entry filter but the lookup still resolves the entry using only Order No./Order Line No. (the production order and line), not "Prod. Order Comp. Line No." (the specific component within that order line). When a production order line has multiple components sharing the same item and variant, FindFirst can bind "Applies-to Entry" to a transfer entry that actually belongs to a different component of the same order/variant, causing the applied entry to diverge from the one the Delivery Challan Line's Remaining-Quantity FlowField (which the PR now filters by Prod. Order Comp. Line No.) actually represents. Add a "Prod. Order Comp. Line No." filter to the Item Ledger Entry lookups so they use the same discriminator set as the FlowField they support.

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

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

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Performance}$

The changed "Remaining Quantity" FlowField on "Delivery Challan Line" now filters Item Ledger Entry by Variant Code, Order No., Order Line No., and Prod. Order Comp. Line No. in addition to the previous fields, but the source table "Item Ledger Entry" has no matching SIFT key covering these fields with "Remaining Quantity" in SumIndexFields. Each CalcFields on this FlowField (used in validation and lookup paths added in this PR) therefore aggregates matching ledger rows directly instead of using a maintained sum, which is costly on ledger-backed lookup/validation paths that run per document line.

Knowledge:

• microsoft/knowledge/performance/flowfield-source-key-needs-sumindexfields.md

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

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