[Subcontracting] Remove Subcontracting Purchase Provisioning Wizard

[SPinkow]

Remove Subcontracting Purchase Provisioning Wizard temporary from Subcontracting App.
It will be added again if the necessary parts are moved to the BaseApp.

What & why

These changes removes the Subcontracting Purchase Provizioning Wizard and the related tests. The Wizard will be moved to the BaseApp. Because this dependency on the base app does not exists for this build now we decided to first remove the wizard and add the subcontraction app related festures and tests later agian.

Details about the changes:
This pull request makes significant changes to the Subcontracting app by removing dependencies on the custom Subc. Management Setup table and related objects, consolidating setup logic onto the standard Manufacturing Setup table. It also removes several obsolete codeunits and pages, and updates permissions accordingly. The changes improve maintainability and align the app more closely with standard manufacturing features.

Key changes:

Removal of Subc. Management Setup and related objects

• All references to the Subc. Management Setup table and its data access have been removed from codeunits, replacing them with the standard Manufacturing Setup table. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
• The obsolete Subc. Management Setup page and related codeunits and pages have been deleted (Subc. CrPurchSubcon(Yes/No), Subc. ItemJnlCheckExt, Subc. Create Prod. Rtng. Ext.). [1] [2] [3]

Permissions and security updates

• Permissions for the removed table, pages, and codeunits have been deleted from all relevant permission sets (Subcontract. - Objs, Subcontract. - Read, Subcontract. - Edit). [1] [2] [3] [4] [5] [6] [7] [8]

Setup and initialization changes

• The business setup extension now registers the standard Manufacturing Setup page instead of the removed Subc. Management Setup page.
• The company initialization logic has been updated to initialize manufacturing setup defaults instead of custom subcontracting setup.

Dependency and namespace updates

• Added necessary using Microsoft.Manufacturing.Setup; statements to files now using Manufacturing Setup. [1] [2] [3]

Linked work

Fixes AB#619329

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)

Risk & compatibility

None

[github-actions]

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

Double Get() on same record in CalcStandardCost

In CalcStandardCostOnAfterCalcRtngLineCost, the instance variable ManufacturingSetup is fetched with ManufacturingSetup.Get() at line 124 as an early-exit guard (loading all fields), and then fetched again with ManufacturingSetup.SetLoadFields("Cost Incl. Setup") + ManufacturingSetup.Get() at lines 158–159. The second fetch is redundant since the record is already loaded.

Recommendation:

• Remove the early-exit ManufacturingSetup.Get() at line 124 and instead consolidate to a single SetLoadFields + Get() call before the first field access, or check existence separately without a full load.

Suggested change

	if not ManufacturingSetup.Get() then
	begin
	ManufacturingSetup.SetLoadFields("Cost Incl. Setup");
	if not ManufacturingSetup.Get() then
	exit;
	// ... rest of guard checks ...
	// Use ManufacturingSetup."Cost Incl. Setup" directly — no second Get() needed

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

[github-actions]

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

ItemChargeToRcptSubReferenceEnabled ignores Rec

The method ItemChargeToRcptSubReferenceEnabled() is an instance method on the Manufacturing Setup table extension, yet it ignores Rec and instead declares a local ManufacturingSetup variable to perform a fresh Get(). Every caller (e.g. SubcItemChargeAssPurchExt, SubcPurchPostExt) that already has the record loaded will still trigger a database roundtrip unnecessarily.

Recommendation:

• Use Rec directly inside the method instead of declaring a local variable and calling Get(). If callers may invoke it on an unloaded instance, document the contract clearly.

Suggested change

	internal procedure ItemChargeToRcptSubReferenceEnabled(): Boolean
	internal procedure ItemChargeToRcptSubReferenceEnabled(): Boolean
	begin
	exit(Rec.RefItemChargeToRcptSubLines);
	end;

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

[github-actions]

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

Trailing newline removed from Codeunit file

This PR changes the final } of SubcPurchFactboxMgmt.Codeunit.al from a line with a trailing newline to one without (\ No newline at end of file). The original file was correct; the change is a regression that can cause AL compiler warnings and noisy Git diffs.

Recommendation:

• Add a trailing newline at the end of the file to restore the original formatting.

    end;
}

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

Trailing newline removed from test Codeunit file

The final } of SubcSubcontractingUITest.Codeunit.al was changed from having a trailing newline (correct) to missing one (\ No newline at end of file). This is a regression from the original, can produce AL compiler warnings, and will show up as a spurious change in future diffs.

Recommendation:

• Restore the trailing newline at the end of the file.

        SubcontractingActionsNotEnabledErr: Label 'Subcontractor Prices action should be enabled for a subcontracting Work Center.';
}

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

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

[github-actions]

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

Manual Setup entry opens unscoped Manufacturing Setup

The "Subcontracting App" manual setup entry now navigates users to the generic Manufacturing Setup page instead of the former dedicated Subc. Management Setup page. Users searching for subcontracting configuration will land on a page that exposes all manufacturing settings, making it easy to accidentally modify unrelated fields.

Recommendation:

• If a subcontracting-specific setup page is not yet ready, consider either removing the manual setup registration entirely until a replacement page exists, or routing to a page that filters to only the subcontracting-relevant fields.

Suggested change

	sender.InsertManualSetup(SubcontractingLbl, SubcontractingLbl, SubcontractingDescriptionLbl, 0, ObjectType::Page, Page::"Manufacturing Setup", ManualSetupCategory::Uncategorized, SubcontractingKeyWordsLbl);
	// Option A: Remove the manual setup registration until a dedicated page is available
	// (delete the OnRegisterManualSetup event subscriber)
	// Option B: Keep but update the description to clarify the page scope
	sender.InsertManualSetup(SubcontractingLbl, SubcontractingLbl, ManufacturingSetupDescriptionLbl, 0, ObjectType::Page, Page::"Manufacturing Setup", ManualSetupCategory::Manufacturing, SubcontractingKeyWordsLbl);

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

[github-actions]

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

Redundant ManufacturingSetup2 variable

The refactoring introduced a ManufacturingSetup2: Record "Manufacturing Setup" variable that duplicates exactly what ManufacturingSetup already does a few lines later (both attempt Get()/Init()/Insert() on the same singleton table). The ManufacturingSetup2 block at lines 33–36 sets no fields and its only effect is shadowed by the ManufacturingSetup block at lines 41–44.

Recommendation:

• Remove the ManufacturingSetup2 variable and the corresponding Get/Init/Insert block entirely, keeping only the ManufacturingSetup block.

Suggested change

	ManufacturingSetup2: Record "Manufacturing Setup";
	procedure InitSetupFields()
	var
	Item: Record Item;
	RoutingLink: Record "Routing Link";
	ManufacturingSetup: Record "Manufacturing Setup";
	WorkCenter: Record "Work Center";
	begin
	SubCreateProdOrdWizLibrary.CreateAndCalculateNeededWorkCenter(WorkCenter, true);
	LibraryManufacturing.CreateRoutingLink(RoutingLink);
	LibraryInventory.CreateItem(Item);
	if not ManufacturingSetup.Get() then begin
	ManufacturingSetup.Init();
	ManufacturingSetup.Insert();
	end;
	ManufacturingSetup."Rtng. Link Code Purch. Prov." := RoutingLink."Code";
	ManufacturingSetup."Subc. Default Comp. Location" := ManufacturingSetup."Subc. Default Comp. Location"::Purchase;
	ManufacturingSetup.Modify();
	end;

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