[29.0] Bug 649448: Fully received WIP purchase orders block Disable Legacy Subcontracting

[Chethan Thopaiah (ChethanT)]

Summary

Backport of #12080 to 29.0. Fix the Legacy Subcontracting disable prerequisite so fully received WIP purchase order lines no longer count as open.

Validation

• Cherry-pick applied cleanly to releases/29.0.
• Delta contains only the Base Application fix and its regression test.
• git diff --check passed.

Fixes AB#649448

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Request Changes

What this PR does

This change lets fully received retained WIP purchase-order lines pass the disable prerequisite by checking document Outstanding Quantity. The nonzero filter still blocks positive and negative outstanding quantities and is used by both the pre-check and actual disable flow.

The predicate fixes the immediate false block, but the retained line remains editable after the one-time migration. Increasing Quantity after disable can recreate nonzero legacy WIP when legacy validation is no longer active.

Problem-solution fit

Fit: Partial

The change fixes the reported zero-outstanding false block, but it does not preserve the completion rule after the feature is disabled. The retained line can become outstanding again without another migration.

Suggestions

S1 (🔴 High): Prevent retained WIP lines from becoming outstanding again
This filter allows disable while the retained WIP order remains editable. After migration, increasing Quantity recreates outstanding legacy work, but migration does not run again and legacy validation is disabled. Reject such increases after disable, or close or migrate the retained line so it cannot become outstanding again.

Risk assessment and necessity

Risk: This BaseApp prerequisite controls a one-time migration. The transfer prerequisite uses the analogous nonzero-outstanding rule, but no guard prevents the retained purchase line from reopening legacy work after disable. No public API or event surface changes.

Necessity: Ignoring zero-outstanding retained lines is required so completed orders do not block migration. The scope also needs a lifecycle guard so the same line cannot reopen legacy work after migration.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=12159 round=1 by=alexei-dobriansky at=2026-09-30T18:14:42Z lastSha=af86a6ebcd5bdb72d848a00d25f052bfeca95fa1 reviewKey=54a39abd431095cefd35646080036d0f16c7930d3719ab1fa19ba61483386276 suggestions=S1@fe869322

[Chethan Thopaiah (ChethanT)]

Addressed S1 in 8992573. A Purchase Line quantity-validation subscriber now rejects increasing a completed retained WIP order line when Legacy Subcontracting is disabled, while leaving ordinary purchase lines and legacy-enabled behavior unchanged. Added CannotReopenFullyReceivedWIPPurchaseLineAfterDisabling to cover the post-disable reopening path.

[alexei-dobriansky]

Good Sense Reviewer - Round 2

Recommendation: Request Changes

What this PR does

The latest commit adds a Purchase Line quantity-validation subscriber and a regression test to stop a direct Quantity increase on a completed retained WIP line after Legacy Subcontracting is disabled.

This closes the direct-edit path, but it does not close the full lifecycle issue. Undo Receipt reduces Quantity Received, recalculates Outstanding Quantity, and modifies the order line without validating Quantity, so the retained line can still become outstanding after the one-time transition.

Status of previous suggestions

ID	Title	Status	Author response
S1	Prevent retained WIP lines from becoming outstanding again	Not addressed	Added a Quantity guard and direct-increase test, but Undo Receipt still reopens the retained line.

New observations (commits since round 1)

None - the remaining blocker is the unresolved part of S1.

Risk assessment and necessity

Risk: This is a one-time migration boundary. Undo Receipt calls the standard purchase-line update path, subtracts received quantity, runs InitOutstanding, and modifies the retained line without reaching this new subscriber. That can recreate open legacy WIP after legacy handling is disabled.

Necessity: Ignoring completed lines is required so they do not block migration. The lifecycle guard must also cover receipt undo, or the same retained line can become open again after the migration check can no longer protect it.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=12159 round=2 by=alexei-dobriansky at=2026-10-01T00:32:09Z lastSha=8992573d9a122632901dc90a6dcd7f730c61e84b reviewKey=438ddf1b3ee38c330b476279e852199ce19e68bb54ea714b5f1094961ca677a6 suggestions=S1@fe869322:notaddressed parentRound=1

[Chethan Thopaiah (ChethanT)]

Follow-up lifecycle coverage added in 8a44501: receipt undo is now blocked when it would reopen a completed retained WIP purchase line after Legacy Subcontracting is disabled. The subscribers also moved into a dedicated non-obsolete guard, with focused receipt-undo regression coverage.

[alexei-dobriansky]

Good Sense Reviewer - Round 3

Recommendation: Request Changes

What this PR does

The latest changes add a receipt-undo guard and move the lifecycle checks into a non-obsolete codeunit. Completed retained WIP purchase lines still pass the migration prerequisite based on document Outstanding Quantity.

The receipt-undo subscriber runs before receipt checks and posting, closing the previously identified undo route after disabling. However, nested over-receipt validation can still restore outstanding legacy work. A second session can also undo a completed receipt during migration confirmation, before the migration locks are taken.

Problem-solution fit

Fit: Partial

The completion filter fixes the false migration block, and receipt undo after disabling is now protected. The retained line can still become outstanding through over-receipt validation or concurrent receipt undo during transition.

Status of previous suggestions

ID	Title	Status	Author response
S1	Prevent retained WIP lines from becoming outstanding again	Not addressed	Receipt undo after disabling is now stopped before posting, but nested over-receipt validation still bypasses the quantity guard.

S1 (🔴 High): Prevent retained WIP lines from becoming outstanding again
Remove the CurrentFieldNo restriction from PreventQuantityIncrease. Editing Over-Receipt Quantity on a completed WIP order calls Validate(Quantity) under the originating field context, so the guard can be skipped and outstanding legacy work restored after disabling. Add a regression test for this supported over-receipt path.

New observations (commits since round 2)

S3 (🔴 High): Recheck open WIP after taking migration locks
Recheck the open-WIP prerequisites under migration locks after confirmation and before disabling Legacy Subcontracting. While confirmation is open, another session can undo a completed WIP receipt because this guard still sees legacy enabled; migration then skips that now-outstanding WIP line and disables legacy. Add a two-session regression for this sequence.

S2 (🟠 Moderate): Cover permitted receipt undo and mixed selections
Add a successful receipt-undo test for a non-WIP order while Legacy Subcontracting is disabled. Also test a mixed selection containing a completed WIP line and assert that no selected line is reversed. The new test covers only one blocked receipt, leaving these selection and pass-through paths uncovered.

Risk assessment and necessity

Risk: A released retained WIP order with Quantity and Quantity Received both 10 can use an allowed over-receipt of 1 to validate Quantity as 11. The originating field is not Quantity, so the guard exits and Outstanding Quantity becomes 1. Receipt undo can also reopen the line while migration confirmation is open: the prerequisite is checked before confirmation, but is not repeated after locks are taken. Migration excludes WIP lines and its count verification does not detect the reopened line. The separate transfer prerequisite remains unchanged. Tests were inspected, not executed.

Necessity: Completed retained orders must not block transition or require deletion. The receipt-undo protection after disabling is needed and correctly placed, but nested validation and concurrent changes during confirmation must also be covered to preserve that migration boundary.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=12159 round=3 by=alexei-dobriansky at=2026-10-01T13:11:11Z lastSha=80e95137cb97d33dbb10d9cdbe12958e7b4a1508 reviewKey=9481d15617863de0b13f0896a59d5f2b98bf845e2c3c648f61811752ae7afcaa suggestions=S1@fe869322:notaddressed,S3@cf7c2e33:new,S2@e7d4d86d:new parentRound=2