CS12 — Summarized Multi-Level BOM Explosion

CS12 explodes a material's BOM through every level down to the lowest raw material or purchased part, then rolls up every occurrence of each component into one summarized quantity for the top-level quantity entered. The structural fact that explains most confusion: summarization means a component appearing in two different sub-assemblies, each with its own quantity, is shown as a single combined figure, with no indication of where each portion came from. Anyone reconciling this number against a specific sub-assembly's consumption has to fall back to CS11 or drill into the item detail. CS12 is purely a display report built on the current BOM master data at the selected explosion date; it writes nothing and has no persistence of its own.

CS12 is reached for when someone needs a single, consolidated quantity of a component required to build one unit of a top assembly, independent of how many sub-assemblies use it or at what level. Typical uses: sizing a purchasing or make-vs-buy decision, checking total raw material consumption before a large sales order or forecast, or auditing a BOM change before it hits MRP. It differs from MD04, which shows actual planned and confirmed requirements from live orders and MRP runs; CS12 is a static, point-in-time explosion of the BOM as designed, not what has actually been planned or produced. It is chosen over CS11 specifically when the indented structure is not needed and only the bottom-line total matters.

There is nothing to prove by checking a save, since CS12 saves nothing; the goal is to confirm the summarized figure matches the underlying data. In SE16, pull MAST filtered on material and plant to find the BOM group, then STKO filtered on that group and the usage/alternative shown on the CS12 selection screen, checking STKO validity dates bracket the explosion date used. Pull STPO for that BOM number and check each item's validity dates and deletion flag against the same explosion date; a component missing from CS12 usually has a validity window or deletion flag that excludes it on that date.

CS12 behaves the same on S/4HANA as on ECC; the underlying BOM tables and explosion logic are unchanged for this reporting transaction. S/4HANA offers newer Fiori apps for BOM display and management that present similar explosion information in a modern UI, but the exact app naming varies by release and should be verified in the relevant app catalog rather than assumed. For anyone working primarily in the GUI, CS12 remains a reliable, unchanged fallback for a quick summarized total.

This is functional territory, owned by whoever maintains BOM master data, typically a PP or classification (CS) consultant, not Basis or ABAP. A good handover includes the exact material, plant, BOM usage, alternative, and explosion date used, plus a screenshot or export of the summarized list, so the receiving consultant can reproduce the exact selection rather than guessing which alternative or date was involved.

Read CS01, CS02 and CS03 first to understand how the BOM itself is built and maintained, since CS12's output is only as good as that structure. CS11 is the natural companion for seeing the indented, non-summarized version of the same explosion when the origin of a quantity needs tracing. CS13 answers the reverse question, where a given component is used across BOMs. CO01 and MD04 are worth understanding afterward, since they show how the same BOM explosion logic feeds into actual production order component determination and MRP-driven requirements, which is where a CS12 discrepancy usually ends up mattering in practice.