[Subcontracting] Block Get Order/Receipt Lines and item charges on undone subcontracting receipts

[alexei-dobriansky]

Fixes AB#632785 and AB#637503 by blocking subcontracting scenarios that aren't supported and corrupt cost.

632785 - subcontracting lines must not be invoiced through a separate document:

• Exclude subcontracting receipt lines (Prod. Order No. set) from Get Receipt Lines and block copying them, in SubcPurchPostExt (Purch.-Get Receipt subscribers).
• Exclude subcontracting purchase order lines from Get Order Lines, via the new Matched Order Line Mgmt. filter event.

637503 - item charges against undone subcontracting receipts create orphaned capacity cost:

• Block assigning an item charge to an undone (Correction) subcontracting receipt line in SubcItemChargeAssPurchExt.
• Block posting an item charge assigned to an undone subcontracting receipt line in SubcPurchPostExt.

Tests: lightweight mock-based tests in SubcSubcontractingTest covering all three blocks.

Recreated from #8678 on a clean branch off latest main (resolves the folder-rename conflict).

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Wrong identifier field for subcontracting check

The undone-receipt guard uses "Prod. Order No." (the standard BC field) to identify a subcontracting line, but the event handler above (line 30) uses "Subc. Prod. Order No." (the extension field) as the definitive subcontracting identifier. A real subcontracting receipt line may have "Subc. Prod. Order No." <> '' while "Prod. Order No." = '', which would allow assigning item charges to an undone line without raising an error.

Recommendation:

• Replace FromPurchRcptLine."Prod. Order No." <> '' with FromPurchRcptLine."Subc. Prod. Order No." <> '' to be consistent with the rest of the handler and correctly identify subcontracting lines.

Suggested change

	if (FromPurchRcptLine."Prod. Order No." <> '') and FromPurchRcptLine.Correction then
	if (FromPurchRcptLine."Subc. Prod. Order No." <> '') and FromPurchRcptLine.Correction then
	Error(AssignToUndoneRcptErr, FromPurchRcptLine."Document No.", FromPurchRcptLine."Line No.");

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Mock missing "Subc. Prod. Order No." — test never reaches new guard

MockSubcontractingPurchRcptLine sets "Prod. Order No." but not "Subc. Prod. Order No.". The event handler OnBeforeCreateRcptChargeAssgnt exits early at if FromPurchRcptLine."Subc. Prod. Order No." = '' then exit (line 30 of the production codeunit), so CreateRcptChargeAssgnt is never called and AssignToUndoneRcptErr is never raised. The asserterror in AssignItemChargeToUndoneSubcontractingReceiptIsBlocked will therefore fail with "there was no error".

Recommendation:

• Add PurchRcptLine."Subc. Prod. Order No." := CopyStr(LibraryUtility.GenerateGUID(), 1, MaxStrLen(PurchRcptLine."Subc. Prod. Order No.")); to MockSubcontractingPurchRcptLine so the handler proceeds past the early-exit check and reaches the new undone guard.

Suggested change

	PurchRcptLine."No." := Item."No.";
	PurchRcptLine."Prod. Order No." := CopyStr(LibraryUtility.GenerateGUID(), 1, MaxStrLen(PurchRcptLine."Prod. Order No."));
	PurchRcptLine."Subc. Prod. Order No." := CopyStr(LibraryUtility.GenerateGUID(), 1, MaxStrLen(PurchRcptLine."Subc. Prod. Order No."));
	PurchRcptLine."Routing No." := CopyStr(LibraryUtility.GenerateGUID(), 1, MaxStrLen(PurchRcptLine."Routing No."));

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

[github-actions]

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

Duplicate subscribers may suppress expected error in test

ExcludeSubcontractingLinesOnAfterPurchRcptLineSetFilters adds SetRange("Prod. Order No.", '') to the iteration record, silently filtering out subcontracting lines before the loop runs. If this event fires on the same record instance that CreateInvLines iterates, BlockSubcontractingLinesOnCreateInvLinesOnBeforeInsertLineIteration (which throws GetSubcontractingRcptNotSupportedErr) will never be reached, and GetReceiptLinesBlocksSubcontractingReceiptLine's asserterror would fail because no error is thrown.

Recommendation:

• Verify (via a debug run or base-codeunit inspection) that OnAfterPurchRcptLineSetFilters operates on a different record instance than the one iterated in OnCreateInvLinesOnBeforeInsertLineIteration. If both events touch the same record, remove the filter subscriber and rely solely on the error-throwing subscriber, or adjust the test to assert no lines are returned instead of asserting an error.

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