[Main]- Production order can be deleted with registered unconsumed warehouse picks

[DeepsShukla]

Workitem Bug 647854: [All-E] [Repair Item] Production order can be deleted with registered unconsumed warehouse picks

Fixes AB#647854

[github-actions]

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

Replacing the previous confirm-based deletion check with a hard Error() is a user-visible breaking change. Before this change, users could still proceed with deletion after acknowledging the warning, and locations whose production warehouse handling was configured as No Warehouse Handling bypassed the check entirely. Preserve that compatibility path or stage the stricter behavior as an explicit migration, otherwise existing production-order, line, and component deletion flows will start failing immediately.

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

[github-actions]

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

Replacing the previous confirm-based deletion check with a hard Error() is a user-visible breaking change. Before this change, users could still proceed with deletion after acknowledging the warning, and locations whose production warehouse handling was configured as No Warehouse Handling bypassed the check entirely. Preserve that compatibility path or stage the stricter behavior as an explicit migration, otherwise existing production-order, line, and component deletion flows will start failing immediately.

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

The replacement error for picked-quantity deletion is hard-coded to "You cannot delete the production order..." even though this path is deleting a Prod. Order Component record. That gives the user the wrong operation name in the error dialog. Use component-specific text here, or parameterize the helper so the message can reflect the record actually being deleted.

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

The new CannotDeleteWithPickedQtyErr text says the user cannot delete "the production order", but this label is raised from Prod. Order Component deletion and is also reused by the new Prod. Order Line deletion path. That makes the blocked operation read incorrectly for component and line deletes. Tailor the message to the actual delete target, or pass the caller caption into the shared check so each path reports the right entity.

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

[github-actions]

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

The production-order-line deletion scan loops over every component on the line even though only components with picked quantity can fail the new check. Filter "Qty. Picked (Base)" before FindSet() so the loop only evaluates rows that can actually block deletion.

Suggested change

	ProdOrderComponent.SetRange(Status, Status);
	ProdOrderComponent.SetRange("Prod. Order No.", "Prod. Order No.");
	ProdOrderComponent.SetRange("Prod. Order Line No.", "Line No.");
	if ProdOrderComponent.FindSet() then
	repeat
	ProdOrderComponent.CheckPickedQtyBeforeDeletion();
	until ProdOrderComponent.Next() = 0;
	ProdOrderComponent.SetRange(Status, Status);
	ProdOrderComponent.SetRange("Prod. Order No.", "Prod. Order No.");
	ProdOrderComponent.SetRange("Prod. Order Line No.", "Line No.");
	ProdOrderComponent.SetFilter("Qty. Picked (Base)", '>%1', 0);
	if ProdOrderComponent.FindSet() then
	repeat
	ProdOrderComponent.CheckPickedQtyBeforeDeletion();
	until ProdOrderComponent.Next() = 0;

Knowledge:

• microsoft/knowledge/performance/apply-filters-before-iterating.md

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

[github-actions]

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

The production-order deletion scan iterates every component for the order even though components with zero picked quantity can be excluded up front. Add a SetFilter("Qty. Picked (Base)", '>%1', 0) before FindSet() so rows that cannot trigger CheckPickedQtyBeforeDeletion() never cross the AL loop.

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

        ProdOrderComponent.SetRange(Status, Rec.Status);
        ProdOrderComponent.SetRange("Prod. Order No.", "No.");
        ProdOrderComponent.SetFilter("Qty. Picked (Base)", '>%1', 0);
        if ProdOrderComponent.FindSet() then
            repeat
                ProdOrderComponent.CheckPickedQtyBeforeDeletion();
            until ProdOrderComponent.Next() = 0;

Knowledge:

• microsoft/knowledge/performance/apply-filters-before-iterating.md

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

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Request Changes

What this PR does

This change blocks released production order, production order line, and component deletion when a component has picked quantity that has not been consumed. The new check runs before header deletion cascades, and the direct line and component paths are covered too. Using base quantities is the right direction, and the new tests cover the blocked header, line, and component paths. However, the guard still uses cumulative picked quantity only, so it does not prove the picked stock is still outstanding after a return movement.

Problem-solution fit

Fit: Partial

The change fixes the main reported failure by preventing deletion while registered picked quantity is still unconsumed. It does not fully match the requested behavior because a returned picked quantity can still leave the stored picked quantity higher than consumed quantity.

Suggestions

S1 (🔴 High): Account for returned picked quantity
The check uses cumulative Qty. Picked (Base) as if every unconsumed pick is still in the operation area. A supported return movement can move stock out without reducing this field, so deletion can still be blocked after the quantity is returned. Base the guard on outstanding picked quantity, or update the value this check uses when the return is registered.

Risk assessment and necessity

Risk: The changed area protects manufacturing production orders that use warehouse picks. If the guard is too weak, warehouse entries and bin content can be left without the production document needed for reconciliation. If it is too broad, users can be blocked from deleting an order after they have already moved the stock back through a supported return flow. The tests cover the new blocked deletion paths, but not the return/success path.

Necessity: The change is needed because the old confirmation allowed a released production order to be deleted after a registered pick but before consumption. The scope is focused on the right delete paths, but it needs to recognize when picked quantity is no longer outstanding.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11261 round=1 by=alexei-dobriansky at=2026-09-09T12:04:44Z lastSha=333c7894b10f213f2778ddf4519119ec00e5bbc3 reviewKey=e3047268b5b4aa92d91b706ad36997b9c27ca77a62173b3583bef9dc5da9212c suggestions=S1@d50b13ad