CS11 — Display Multi-Level BOM Explosion
CS11 is a display-only transaction that explodes a material's bill of material through all levels, showing every subassembly and component down to raw materials for a given plant, BOM usage, and validity date. It reads the BOM tables directly and writes nothing back, so it is safe to run against production data at any time.
This page covers CS11, the multi-level BOM explosion display in PP, and why an explosion that looks incomplete is almost always a selection parameter problem rather than a missing master data record. It walks through the entry sequence, the underlying tables, and the diagnostic order for chasing a BOM that will not explode the way engineering expects.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,049 words
Purpose
CS11 shows the full multi-level structure of a material's bill of material: the finished good, its immediate components, and then recursively the components of every subassembly beneath it, down to the lowest level that has no further BOM. It is a report, not a maintenance transaction — it cannot create or change a BOM item. The structural fact behind most confusion is that the explosion is driven by three selection parameters entered on the initial screen: BOM usage, plant, and explosion date (validity date). Change any one of those and a completely different tree can appear, because a material can carry several alternative BOMs and several usages simultaneously, each valid for a different date range.
When it is used
CS11 is reached for whenever someone needs to see the whole product structure rather than one level of it: engineering review of a finished good's full parts list, verifying what a costing run or MRP explosion will actually consume, or checking why a production order pulled components that do not match expectations. CS03 answers 'what does this one BOM contain'; CS11 answers 'what does this product actually build down to raw material'. It is also the fastest way to confirm, before troubleshooting CO01 or MD01, whether the BOM structure itself is the source of a shortage or a wrong component, rather than the order or the planning run.
How to use it in practice
- Enter the material number and plant on the initial screen.
- Enter the BOM usage (production, engineering, costing, etc.) — this is mandatory and drives which alternative BOM is picked up.
- Enter the explosion date (validity date) that determines which BOM version and which item validity ranges apply.
- Optionally restrict the explosion level or select 'with history requirement' if engineering change management context matters.
- Execute; the result is a hierarchical tree that can be expanded, collapsed, or switched to a flat multi-level list view.
Key data objects
- MAST - links a material and plant to the BOM number(s) assigned to it, one row per usage.
- STKO - the BOM header, holding the BOM number, alternative, validity dates, and status.
- STPO - the BOM item table, holding each component, its quantity, unit, item category, and deletion indicator.
- STAS - the BOM to material assignment record used to resolve which alternative applies for the usage entered.
- STZU - change-history and quantity-usage link used when engineering change numbers or lot-size ranges are involved.
How to prove it in the data
Start in MAST filtering on material and plant to find every BOM number and usage assigned to it. Take the BOM number into STKO and check the validity date range (BOM_ANRUE, DATUV/DATUB fields) against the explosion date used in CS11 — a date outside that window explains a truncated tree. Then filter STPO on that BOM number for the item that is missing or unexpected, and check its own validity dates and deletion indicator (LKENZ), since an item can be excluded even when the header BOM is fully valid.
ECC vs S/4HANA
CS11 exists and behaves the same way on S/4HANA; the underlying BOM tables are unchanged in structure and content. A Fiori app for displaying bill of material information is available for users who prefer the web interface, but the classic transaction remains fully supported and is what most PP consultants still use for troubleshooting because the tree navigation and level filtering are faster in the SAP GUI view.
Common pitfalls and how to diagnose them
- Explosion stops one level early: the subassembly has a BOM, but not for the usage or plant entered on the selection screen. Check MAST for that subassembly directly before assuming the BOM is missing.
- Wrong alternative BOM picked up: multiple alternatives exist and the one shown does not match what production is actually using. Confirm which alternative is linked via the production version, then re-run CS11 forcing that BOM number explicitly rather than relying on usage/date selection alone.
- Item present in CS03 but missing in CS11: a validity date or engineering change number excludes the item on the date entered for the multi-level explosion. Re-run with the correct explosion date rather than editing the item.
- Phantom assembly not exploding through: the phantom item category flag is set incorrectly, or the phantom's own BOM has no valid record for the plant/usage combination, so the explosion treats it as a normal component and stops.
- Circular reference error: the system aborts the explosion with a message about a recursive structure. This means a component BOM somewhere in the tree references an ancestor material; it has to be fixed in CS02 on the offending level, not worked around in CS11.
- Explosion looks right but costing or MRP behaves differently: those transactions may use a different BOM usage by configuration default than the one manually entered in CS11, so the comparison was never apples to apples.
Whose problem this is
This sits with the PP or PLM functional consultant responsible for BOM master data. It is rarely an ABAP or Basis issue unless a custom program calls the underlying BOM explosion function module and returns different results than CS11 itself. A good handover includes the exact material, plant, BOM usage, and explosion date used, plus a screenshot of the tree so the next person is not guessing which parameter combination produced the symptom.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/cs11ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.