[Subcontracting] Refactor event subscriber for planning components and add test for Vendor-supplied components

[Sebastian Pinkow GOB (SPinkow)]

What & why

This pull request introduces a targeted fix to the planning logic for vendor-supplied components in the subcontracting manufacturing process. It ensures that components marked as "Vendor-Supplied" do not generate separate planning demand, while still allowing them to appear in the planning worksheet for consumption registration. Additionally, a comprehensive test is added to verify this behavior.

Planning Logic Update:

• The event subscriber previously attached to the OnTransferBOMOnBeforeUpdatePlanningComp event in Mfg. Planning Line Management is replaced with a new subscriber to the OnAfterFilterLinesWithItemToPlan event on the Planning Component table. This new subscriber filters out planning components with the supply method set to "Vendor-Supplied," preventing them from generating separate demand lines. (SubcPlanningLineMgmtExt.Codeunit.al)

Automated Testing Enhancements:

• A new test, VendorSuppliedPlanningComponentNotPlannedSeparately, is added to verify that vendor-supplied components do not generate requisition lines during planning runs, but still remain in the planning worksheet and production order for consumption tracking. The test also checks that if the supply method is changed, the component is once again planned. (SubcSubcontractingTest.Codeunit.al)

Why the PlanningComponent_OnAfterFilterLinesWithItemToPlan subscriber was added

Background

When a BOM component has Component Supply Method = Vendor-Supplied, it means the subcontractor provides that material themselves — it is purchased as part of the subcontracting order, not separately by your company. The existing subscriber on Prod. Order Component already prevented the planning engine from generating a separate purchase requisition when a Released Production Order existed with such a component.

The gap

The planning engine has two separate demand sources it queries when running CalcRegenPlan for a component item:

Demand source | Table | Called when -- | -- | -- Existing production orders | Prod. Order Component | A Released/Firm Planned prod. order exists Existing planning worksheet lines | Planning Component | A prior planning run already created a supply plan for the parent item

The ProdOrderComponent_OnAfterFilterLinesWithItemToPlan subscriber only covered the first case. When the planning engine encountered existing Planning Components (i.e., the parent item had already been planned in the worksheet via CalcRegenPlan or RefreshPlanningLine), those components were not filtered — so a second planning run for the component item would still generate a spurious requisition line, even though the component would already be covered by the subcontracting purchase order.

What the new subscriber covers

PlanningComponent_OnAfterFilterLinesWithItemToPlan closes this gap. When the planning engine asks "which Planning Components constitute demand for this item?", the subscriber excludes any component with Component Supply Method = Vendor-Supplied. The result:

• The Planning Component record remains in the worksheet — it is still needed for consumption registration (posting output) against the subcontracting operation.
• No separate Requisition Line is generated for the component item — it will be purchased through the subcontracting purchase order, not independently.
• When the planning line is subsequently carried out to create a production order (MakeSupplyOrders), the Prod. Order Component with Vendor-Supplied is correctly transferred and present in the production order — it was never removed, only excluded from demand calculation.

In one sentence

Without this subscriber, a component marked as Vendor-Supplied would be ordered twice whenever the parent item had an active planning worksheet line: once implicitly through the subcontracting purchase order, and once explicitly through a separate requisition generated by the planning engine reading the Planning Component as unmet demand.

Linked work

Fixes AB#630597

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]

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.

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This PR moves the vendor-supplied planning exclusion from the BOM transfer area to Planning Component.OnAfterFilterLinesWithItemToPlan, and adds a regression test for a component item planned after a parent planning worksheet line already exists. I verified the BaseApp publisher exists and is raised after Planning Component.FilterLinesWithItemToPlan sets the normal item, location, date, quantity, and UOM filters, but before the planning engine reads the records through Plng. Component Invt. Profile.

The code change is the right extension point for this scenario. It keeps vendor-supplied Planning Components in the worksheet, while excluding them from demand calculation; the existing Prod. Order Component subscriber still covers the production-order path. The removed OnTransferBOMOnBeforeUpdatePlanningComp subscriber did not change UpdateCondition or IsHandled, so removing it should not drop the visibility behavior fixed by the earlier Planning Worksheet bug. The new test exercises the refactored Planning Component subscriber path.

Suggestions

None. The linked work item is missing from the PR body, but this is being supplied separately, so it is not treated as a blocker here. Please make sure the approved issue or AB# work item is linked before merge so Work Item Validation passes.

Risk assessment and necessity

Risk: The code risk is narrow: it adds one filter to Planning Component demand reads when Subcontracting is enabled. If this filter were wrong, vendor-supplied components could either create duplicate demand or be hidden from needed planning demand. There is no public API or schema change, and the new test covers the refactored Planning Component subscriber path.

Necessity: The diff describes a valid and important fix: vendor-supplied subcontracting components should not be planned as separate component demand after the parent item is already in the Planning Worksheet. The scenario is clear and the scope is right for a bug fix.

---

[AI-PR-REVIEW] version=1 system=github pr=9130 round=1 by=alexei-dobriansky at=2026-07-06T13:23:50Z lastSha=817b70ac80509cd1aa22aec61ec90da57dc3b883 suggestions=none

[github-actions]

Copilot PR Review

Iteration 1 · Outcome: completed

All applicable sub-skills completed; al-upgrade-review and al-ui-review were not-applicable (no upgrade/schema or page/UI surface in the diff). No knowledge-backed or agent findings cleared the precision bar.

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Orchestrator pre-filter (13 file(s) excluded)

• layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}