Bug 633674: [Subcontracting] Subcontracting Type field and enum captions are unclear — rename to Component Supply Method

[ChethanT]

Bug Summary

The Subcontracting Type wording was unclear in Subcontracting pages and enum captions. The labels implied a subcontracting classification instead of the actual intent: how components are supplied to the subcontractor.

Root Cause

User-facing names and captions did not reflect the functional meaning of the field and enum values, which caused confusion in UI interpretation and setup decisions.

Fix

• Renamed enum object from Subcontracting Type to Component Supply Method.
• Updated enum value captions:
  • Purchase with Service -> Vendor-Supplied
  • Inventory by Vendor -> Consignment at Vendor
  • Transfer -> Transfer to Vendor
• Updated related captions/tooltips/messages in Subcontracting App to align terminology.
• Updated references in app/test AL code to the renamed enum object.

Test Added

• Codeunit: 139990 (Subc. Subcontracting UI Test)
• Test function: ComponentSupplyMethodCaptionsAreClear
• Coverage:
  • Verifies field caption is Component Supply Method on Production BOM Line, Planning Component, and Prod. Order Component.
  • Verifies enum value captions are Vendor-Supplied, Consignment at Vendor, and Transfer to Vendor.

Validation

• App compiles and publishes.
• Tests run and pass.

AB#633674

[ChethanT]

@SPinkow

[github-actions]

AL Documentation Audit

Documentation gaps were detected in the following apps:

• Subcontracting-Test: 0% documentation coverage
• Subcontracting: 0% documentation coverage

To generate documentation, run /al-docs init or /al-docs update using GitHub Copilot CLI or Claude Code.
This review is for awareness to help keep documentation in sync with code changes. It is okay to dismiss this request.

[alexei-dobriansky]

I see that this jargon is used by people who work with subcontracting process. It's confusing, though, who owns the stock - we or subcontractor.

[ChethanT]

Isn't it a matter of documentation, tooltip and code comment?

[github-actions]

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

Transfer header lookup ignores purchase order scope

The filter TransferHeader.SetRange("Subcontr. Purch. Order No.", "Purchase Header"."No.") was removed from the transfer-header lookup. The query now matches any transfer order with the same from/to locations, so components from the current purchase order can be appended to a transfer order belonging to a completely different purchase order that shares those locations.

Recommendation:

• Restore the "Subcontr. Purch. Order No." range filter so the lookup is scoped to the current purchase order only.

TransferHeader.SetRange("Transfer-from Code", CompLineLocation);
TransferHeader.SetRange("Transfer-to Code", TransferToLocationCode);
TransferHeader.SetRange("Return Order", false);
TransferHeader.SetRange("Subcontr. Purch. Order No.", "Purchase Header"."No.");
if not TransferHeader.FindFirst() then begin

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

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

[github-actions]

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

Transfer order lookup missing purchase order filter

The TransferHeader.SetRange("Subcontr. Purch. Order No.", "Purchase Header"."No.") filter was removed before the FindFirst() call. The query now matches any transfer header with the same transfer-from/transfer-to locations, regardless of which purchase order it belongs to, so a transfer order from a completely different subcontracting PO can be reused and updated.

Recommendation:

• Reinstate the SetRange("Subcontr. Purch. Order No.", ...) filter before FindFirst() to ensure only transfer orders belonging to the current purchase order are considered.

TransferHeader.SetRange("Transfer-from Code", CompLineLocation);
TransferHeader.SetRange("Transfer-to Code", TransferToLocationCode);
TransferHeader.SetRange("Return Order", false);
TransferHeader.SetRange("Subcontr. Purch. Order No.", "Purchase Header"."No.");
if not TransferHeader.FindFirst() then begin

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

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

[github-actions]

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

Transfer order lookup missing purchase-order filter

The filter TransferHeader.SetRange("Subcontr. Purch. Order No.", "Purchase Header"."No.") was removed from the TransferHeader lookup before FindFirst(). Without it, the report finds the first transfer order matching only the from/to location codes, which may belong to a completely different purchase order. Lines for the current PO will then be inserted into the wrong transfer order, causing data corruption.

Recommendation:

• Restore the purchase-order number filter to ensure only transfer orders linked to the current subcontracting purchase order are reused.

TransferHeader.SetRange("Transfer-from Code", CompLineLocation);
TransferHeader.SetRange("Transfer-to Code", TransferToLocationCode);
TransferHeader.SetRange("Return Order", false);
TransferHeader.SetRange("Subcontr. Purch. Order No.", "Purchase Header"."No.");
if not TransferHeader.FindFirst() then begin

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}}$

Duplicate field assignment — dead code

ProdOrderComponent."Component Supply Method" is assigned from TempProdOrderComponent twice consecutively on lines 1178 and 1182, with unrelated assignments in between. The second assignment is redundant and was already a bug before this rename.

Recommendation:

• Remove the duplicate assignment on line 1182.

        ProdOrderComponent."Component Supply Method" := TempProdOrderComponent."Component Supply Method";
        ProdOrderComponent."Orig. Location Code" := TempProdOrderComponent."Orig. Location Code";
        ProdOrderComponent."Orig. Bin Code" := TempProdOrderComponent."Orig. Bin Code";
        // Remove the second identical assignment below
        ProdOrderComponent.Modify(true);

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}}$

Missing newline at end of file

The Production BOM Line table extension file is missing a trailing newline (\ No newline at end of file), inconsistent with other files in the codebase.

Recommendation:

• Add a newline character after the closing } at the end of the file.

}

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

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

[github-actions]

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

Invalid enum identifier in location test

UpdateProdBomWithSubcontractingType is called with "Component Supply Method"::TransferToVendor which is not a defined identifier in the new enum. The correct identifier is "Transfer to Vendor", and the same error recurs at line 404.

Recommendation:

• Replace ::TransferToVendor with ::"Transfer to Vendor" at all call sites in this file.

UpdateProdBomWithSubcontractingType(Item, "Component Supply Method"::"Transfer to Vendor");

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

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

[github-actions]

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

Invalid enum identifier in sync test

UpdateProdBomWithSubcontractingType is called with "Component Supply Method"::VendorSupplied but VendorSupplied is not a valid identifier in the new enum; the correct identifier is "Vendor-Supplied". This will cause a compilation error.

Recommendation:

• Change "Component Supply Method"::VendorSupplied to "Component Supply Method"::"Vendor-Supplied".

UpdateProdBomWithSubcontractingType(Item, "Component Supply Method"::"Vendor-Supplied");

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

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

[github-actions]

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

Enum identifier mismatch causes compile error

Test files reference "Component Supply Method"::VendorSupplied, ::TransferToVendor, and ::ConsignmentAtVendor (camelCase, no spaces), but the new enum defines its values as "Vendor-Supplied", "Transfer to Vendor", and "Consignment at Vendor" (quoted identifiers with spaces/hyphens). These identifiers do not exist in the enum and will cause compilation failures.

Recommendation:

• Replace all unquoted camelCase enum value references with the correctly quoted identifiers matching the enum definition.

// Replace:
"Component Supply Method"::VendorSupplied
// With:
"Component Supply Method"::"Vendor-Supplied"

// Replace:
"Component Supply Method"::TransferToVendor
// With:
"Component Supply Method"::"Transfer to Vendor"

// Replace:
"Component Supply Method"::ConsignmentAtVendor
// With:
"Component Supply Method"::"Consignment at Vendor"

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}}$

Inconsistent ToolTip detail across related fields

SubcPlanningCompExt.TableExt.al (line 20) has a comprehensive ToolTip explaining all three enum values, while SubcProdOrderCompExt.TableExt.al and SubcProdBOMLineExt.TableExt.al have single-sentence ToolTips for the same "Component Supply Method" field. This creates an inconsistent user experience depending on which page surface the user interacts with.

Recommendation:

• Align the ToolTip text for "Component Supply Method" across all three table extensions to the same level of detail. Either use the detailed version from SubcPlanningCompExt in all places, or shorten it consistently across all three.

Suggested change

	ToolTip = 'Specifies the Type of Subcontracting that is assigned to the Production Order Component.';
	ToolTip = 'Specifies how components are supplied to the subcontractor for the production order component. Vendor-Supplied - components are provided by the subcontractor. Consignment at Vendor - components are owned by your company but stored at the subcontractor location. Transfer to Vendor - components are sent to the subcontractor through a transfer order.';

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

[github-actions]

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

Field rename breaks AL code in dependent apps

Fields 'Subcontracting Type' (ID 99001522) are renamed to 'Component Supply Method' across three table extensions (Prod. Order Component, Planning Component, Production BOM Line). While the field ID is preserved (so database data is safe), any AL code in dependent extensions or integrations that references the old field name will fail to compile.

Recommendation:

• Document this breaking change prominently in the release notes. If this is a published app, consider whether an obsolete/compatibility field with the old name and field ID pointing to the new field is needed for one release cycle. Also verify no API pages or web services expose the old field name externally.

// Release note example:
// Field 99001522 'Subcontracting Type' has been renamed to 'Component Supply Method'
// on Prod. Order Component, Planning Component, and Production BOM Line.
// Update any AL code referencing the old field name.

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

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