Planning Phantom Assemblies in SAP IBP: Solution Enhancement
Hello all, this blog post is focused on how to plan Phantom Assemblies in SAP IBP.
Introduction:
If you have Phantom Assemblies in your Bills of Materials in SAP ECC or in SAP S/4HANA, and you have tried Supply Planning in SAP IBP, then you may already know that SAP IBP does not currently support Phantom Assemblies.
Phantom Assemblies are natively supported in SAP ERP MRP. This creates a hard gap for Customers looking to use SAP IBP Order Based Supply Planning to replace their SAP ERP based MRP solutions.
GitaCloud team has delivered Phantom Assemblies Planning enhancement, which enables SAP IBP Order Based Planning to be able to plan Phantom Assemblies without breaking the planning situation within SAP IBP or data/integration from/to SAP S/4HANA.
Read content below to understand the Business Requirement, SAP IBP Product Gap, and GitaCloud Solution Enhancement to plan Phantom Assemblies in SAP IBP.
Business Requirement:
Business Requirement is to plan phantom assemblies in SAP IBP OBP in a manner that produces consistent results with SAP IBP OBP Confirmation Run and publishing these results to S/4HANA in a way that both SAP IBP and SAP S/4HANA systems have planning situation consistency.
The phantom assembly represents a logical grouping of materials. These materials are grouped together from the construction point of view and are all maintained together. From the production point of view, however, these materials are normally not assembled.
Phantom Assemblies are identified by Special Procurement Key 50 in MRP1 View of S/4HANA Material Master.
If a BOM item happens to be a phantom assembly, i.e., special procurement key is set-up to be value 50, then the dependent requirements of the higher-level assembly are directly passed on to the components of the phantom assembly. The phantom assembly itself is not considered. This is true in case of nested Phantom Assemblies: where a Lower-level Phantom Assembly is part of a High-level Phantom Assembly.
See example below to understand how (nested) Phantom Assemblies in a multi-level BOM are converted as a Flat BOM in the Planned Order generated by SAP ERP MRP.
SAP IBP Capability Gap:
SAP IBP Order Based Planning (OBP) in the IBP Response & Supply Application does not recognize Phantom Assemblies as any different from a regular Assembly. IBP OBP Confirmation Run generates a Planned Order (MRP Element: PA) to cover the net requirement of the Phantom Assembly. Phantom Assembly BOM (Production Data Structure PDS in IBP) is exploded to create Planned Order Demands (MRP Element: SB) for components in the Phantom Assembly (which may include Lower-level Phantom Assemblies or Components).
IBP creates T-order numbers (T stands for Temporary) in the Confirmation Run prior to the Publish to S/4 and subsequent IBP Inbound job using SDI Integration to perform Key Completion process, which replaces these T-numbered planned orders with corresponding S/4 planned order numbers.
S/4 Planned Order for the Higher-Level Assembly stores MRP Type SB elements to store Planned Order Component Demands in a corresponding Flat BOM.
Planned Orders with T-numbers for Phantom Assemblies are not published to S/4HANA per standard interface code.
At the time of subsequent SDI Data Integration from SAP S/4HANA into SAP IBP OBP, the Higher-level Assembly Planned Order with S/4 number brings all the multi-level SB elements as part of the Flat BOM back into IBP.
This data integration job is not run in ‘Erase Data’ mode, as this will disrupt pegging relationships generated by the Confirmation Run and block any What-If Simulations in Interactive Planning using Projected Stock App given the IBP OBP system needs output from a Confirmation Run to be in place for what-if simulations. Suffice to say, the inbound data integration into IBP must run without erasing data in IBP OBP.
This leaves the Phantom Assembly T-planned orders and associated planned order demands intact, while also bringing the same planned order demands onto the Higher-level assembly with S/4 planned order number (Flat BOM exploding through all Phantom Assemblies). Result is duplicate demands for components in Phantom Assembly BOMs in IBP.
This renders the Projected Stock Negative and breaks the Planners’ ability to make sense of the Planning Results across SAP IBP (duplicate SB demands) and S/4HANA (no Phantom Assembly Planned Orders).
GitaCloud Solution Enhancement:
Given the solution complexity, let’s use a simple example to walk through the end-to-end planning process and situation. Let’s say, we have a High-level Finished Goods Assembly Product called FG1. FG1 has a simple BOM: it needs a Component called Comp1 as well as a Higher-level Phantom Assembly called Phantom1.
This Higher-Level Phantom Assembly Phantom1 in turn explodes to Comp2 and a Lower-level Phantom Assembly Phantom2.
This Lower-level Phantom Assembly Phantom2 explodes to two components: Comp3 and Comp4.
Assume Qty Per to be 1 in all BOMs to make the example simple.
See this BOM relationship below in the graphic.
Let’s say we have a Sales Order #55 / Line Item #20 for FG1 for 10 units to be shipped on March 30th
Let’s assume the following for this example:
Assume zero stock across all materials at the start of planning.
Assume the entire planning is occurring in a single plant 1710.
Assume 10-day Final Assembly Lead Time to produce FG1.
Assume zero GR Processing Lead Time and no Capacity Constraints.
See below Planning Situation for FG1 after SDI Integration and before Confirmation Run in IBP: You can see Projected Stock App logical view below: there is a negative projected stock due to the unplanned Sales Order.
Let’s see how the Planning Situation changes for FG1 and its multi-level BOM components after Confirmation Run in IBP.
Note Projected Stock is zero throughout for all materials, which means Demand and Supply are in perfect balance: no excessive stock and no shortages.
Let’s see how these IBP T-planned orders are published to S/4HANA and how the subsequent SDI data integration step into IBP OBP breaks the planning situation.
/IBP/ORDMAP_Ext table in S/4HANA Add-On for IBP stores the Key Completion information: which IBP T-planned order # maps to which S/4 planned order #.
Please note that this ORDMAP_Ext table will only have records for non-Phantom Assemblies, as S/4HANA publish does not create any S/4 planned orders for Phantom Assemblies. This is why T-234 (Phantom1) and T-345 (Phantom2) are not present in this table.
FG1 Planned Order 555 in S/4 will have the entire Flat BOM worth of SB requirements per PLAF / RESB table logical view in S/4HANA below:
Standard SDI data integration brings the entire set of SB demands for Planned Order #555 back into IBP. This breaks the Planning situation in IBP for all lower-level components: Comp2, Phantom2, Comp3, Comp4 as per snapshot below. The duplicate SB demands from S/4 Planned Order # 555 are noted in Red.
GitaCloud ValueNow for IBP Solution Enhancement removes the duplicate S/4HANA SB demands from being loaded into IBP OBP in order to have a consistent planning result post SDI data integration (key confirmation) per snapshot below.
Please note that IBP T-planned orders for Phantom Assemblies are replaced with corresponding number without the T- (T-234 is converted to 234). Also, all the duplicate demands have been removed, and now the Projected Stock is balanced across all materials.
Business Value:
This approach enables planners to plan the S/4 BOMs fully in IBP OBP including Phantom Assemblies across single or nested Phantom Assemblies. It resolves the Product Gap in IBP SDI Interface to treat Phantom Assemblies as regular materials by completing the key confirmation process also for Phantom Assemblies despite no Phantom Assembly Planned Orders having been created in S/4HANA.
Conclusion:
Hope this gives you a good sense of the solution enhancement and value. It addresses a key interface / modeling gap from Phantom Assembly Planning Process perspective.
GitaCloud has implemented a holistic approach to Order Based Planning that works across the tactical and operational horizons and bridges known gaps in IBP, whether MTO Variant Configuration, Phantom Assemblies, or many others. GitaCloud has packaged this set of holistic solution enhancements as a branded offering: ValueNow for IBP.
Feel free to reach out at connect@gitacloud.com, if you have similar unmet business process requirements with your current SAP IBP implementation or if you have any questions regarding the technical mechanics of this interface enhancement.
