[Bug] Subcontracting Order Lines only for work centers (consistency with subcontracting worksheet)

[SPinkow]

…cy with subcontracting worksheet)

What & why

This pull request introduces a minor update to the Subc. Prod. Order Rtng. page extension in the subcontracting app. The main change is the addition of a filter to only include routing lines of type "Work Center" when showing existing purchase orders for routing lines.

Filtering and dependencies:

• Added a SetRange filter on the Type field to only include "Capacity Type"::"Work Center" routing lines before displaying existing purchase orders in the Subc. Prod. Order Rtng. page extension.

Linked work

Fixes AB#639699

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

• Run in Client and add automatic test

Risk & compatibility

None

[github-actions]

Could not find linked issues in the pull request description. Please make sure the pull request description contains a line that contains 'Fixes #' followed by the issue number being fixed. Use that pattern for every issue you want to link.

[github-actions]

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

var parameter filter mutated as unexpected side effect

CreateSubcontractingOrdersForRoutingLineSelection calls ProdOrderRoutingLine.SetRange(Type, "Capacity Type"::"Work Center") on the var parameter, permanently altering the filter on the caller's record variable. Any code in the caller that uses ProdOrderRoutingLine after this call will silently operate on the narrowed filter set rather than the original selection.

Recommendation:

• Use a local copy of the record to apply the additional filter, keeping the caller's record variable unmodified.

internal procedure CreateSubcontractingOrdersForRoutingLineSelection(var ProdOrderRoutingLine: Record "Prod. Order Routing Line"): Integer
var
    FilteredRoutingLine: Record "Prod. Order Routing Line";
    NoOfCreatedPurchOrder: Integer;
begin
    FilteredRoutingLine.CopyFilters(ProdOrderRoutingLine);
    FilteredRoutingLine.SetRange(Type, "Capacity Type"::"Work Center");
    ShowExistingPurchaseOrdersForRoutingLines(FilteredRoutingLine);
    if FilteredRoutingLine.FindSet() then
        repeat
            NoOfCreatedPurchOrder += CreateSubcontractingPurchaseOrderFromRoutingLine(FilteredRoutingLine);
        until FilteredRoutingLine.Next() = 0;
    exit(NoOfCreatedPurchOrder);
end;

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

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

[github-actions]

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

Test scenario description is completely backwards

The test is named WorkCenterRoutingLinesExcludedFromMultiSelectionWhenMachineCenterPresent and the [SCENARIO] comment states "only the Machine Center lines result in a subcontracting purchase order". However, CreateSubcontractingOrdersForRoutingLineSelection sets SetRange(Type, "Capacity Type"::"Work Center") which includes Work Center lines and excludes Machine Center lines. The assertions at lines 1690/1694 correctly verify that Op 010 (Work Center) gets a purchase order and Op 020 (Machine Center) does not — the opposite of what the name and scenario claim.

Recommendation:

• Rename the test and correct the scenario description to accurately describe what is being tested: that Machine Center routing lines are filtered out and only Work Center routing lines result in subcontracting purchase orders.

[Test]
procedure MachineCenterRoutingLinesExcludedFromSubcontractingOrderCreation()
// [SCENARIO] When CreateSubcontractingOrdersForRoutingLineSelection is called with a mixed
// selection containing both Work Center and Machine Center routing lines, only the
// Work Center lines result in a subcontracting purchase order.
// Machine Center lines are filtered out by the Work Center type filter.

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

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

[github-actions]

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

Test assertions check wrong operation numbers

The test expects PurchaseLine with Operation No. = '010' (the Work Center) to have exactly 1 record, while Operation No. = '020' (the Machine Center) is expected to be empty. Given that CreateSubcontractingOrdersForRoutingLineSelection filters to Type = Work Center, this matches actual behavior. However, if the intent was to create purchase orders for the Machine Center operation '020', the assertions at lines 1690–1695 would need to be swapped.

Recommendation:

• Confirm the intended behavior: should subcontracting purchase orders be created for Work Center lines (Op 010) or Machine Center lines (Op 020)? Align assertions, test name, and scenario description to reflect the confirmed intent unambiguously.

// After confirming Work Center lines produce purchase orders:
PurchaseLine.SetRange("Operation No.", '010');
Assert.RecordCount(PurchaseLine, 1); // Work Center line creates purchase order
PurchaseLine.SetRange("Operation No.", '020');
Assert.RecordIsEmpty(PurchaseLine); // Machine Center line is excluded

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

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

[SPinkow]

🟡 Medium Severity — Performance Iteration 1

var parameter filter mutated as unexpected side effect

CreateSubcontractingOrdersForRoutingLineSelection calls ProdOrderRoutingLine.SetRange(Type, "Capacity Type"::"Work Center") on the var parameter, permanently altering the filter on the caller's record variable. Any code in the caller that uses ProdOrderRoutingLine after this call will silently operate on the narrowed filter set rather than the original selection.

Recommendation:

• Use a local copy of the record to apply the additional filter, keeping the caller's record variable unmodified.

internal procedure CreateSubcontractingOrdersForRoutingLineSelection(var ProdOrderRoutingLine: Record "Prod. Order Routing Line"): Integer
var
    FilteredRoutingLine: Record "Prod. Order Routing Line";
    NoOfCreatedPurchOrder: Integer;
begin
    FilteredRoutingLine.CopyFilters(ProdOrderRoutingLine);
    FilteredRoutingLine.SetRange(Type, "Capacity Type"::"Work Center");
    ShowExistingPurchaseOrdersForRoutingLines(FilteredRoutingLine);
    if FilteredRoutingLine.FindSet() then
        repeat
            NoOfCreatedPurchOrder += CreateSubcontractingPurchaseOrderFromRoutingLine(FilteredRoutingLine);
        until FilteredRoutingLine.Next() = 0;
    exit(NoOfCreatedPurchOrder);
end;

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

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

It is intended to change the filter for all following processes.

[SPinkow]

🟡 Medium Severity — Style Iteration 1

Test assertions check wrong operation numbers

The test expects PurchaseLine with Operation No. = '010' (the Work Center) to have exactly 1 record, while Operation No. = '020' (the Machine Center) is expected to be empty. Given that CreateSubcontractingOrdersForRoutingLineSelection filters to Type = Work Center, this matches actual behavior. However, if the intent was to create purchase orders for the Machine Center operation '020', the assertions at lines 1690–1695 would need to be swapped.

Recommendation:

• Confirm the intended behavior: should subcontracting purchase orders be created for Work Center lines (Op 010) or Machine Center lines (Op 020)? Align assertions, test name, and scenario description to reflect the confirmed intent unambiguously.

// After confirming Work Center lines produce purchase orders:
PurchaseLine.SetRange("Operation No.", '010');
Assert.RecordCount(PurchaseLine, 1); // Work Center line creates purchase order
PurchaseLine.SetRange("Operation No.", '020');
Assert.RecordIsEmpty(PurchaseLine); // Machine Center line is excluded

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

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

Test ist correct, but I have corrected the descriptions

[SPinkow]

🟠 High Severity — Style Iteration 1

Test scenario description is completely backwards

The test is named WorkCenterRoutingLinesExcludedFromMultiSelectionWhenMachineCenterPresent and the [SCENARIO] comment states "only the Machine Center lines result in a subcontracting purchase order". However, CreateSubcontractingOrdersForRoutingLineSelection sets SetRange(Type, "Capacity Type"::"Work Center") which includes Work Center lines and excludes Machine Center lines. The assertions at lines 1690/1694 correctly verify that Op 010 (Work Center) gets a purchase order and Op 020 (Machine Center) does not — the opposite of what the name and scenario claim.

Recommendation:

• Rename the test and correct the scenario description to accurately describe what is being tested: that Machine Center routing lines are filtered out and only Work Center routing lines result in subcontracting purchase orders.

[Test]
procedure MachineCenterRoutingLinesExcludedFromSubcontractingOrderCreation()
// [SCENARIO] When CreateSubcontractingOrdersForRoutingLineSelection is called with a mixed
// selection containing both Work Center and Machine Center routing lines, only the
// Work Center lines result in a subcontracting purchase order.
// Machine Center lines are filtered out by the Work Center type filter.

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

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

Correction done