Peeling Back the Onion: Why a Simple Bill of Materials Gets Complicated Fast 

Written by:

Here’s something I’ve learned working in manufacturing: nothing is ever as simple as it sounds. Take the phrase “just make something.” Two words. Massive complexity. 

Let’s start with something most of you already know, the Bill of Materials, or BOM. If you’ve never heard the term, you can basically reverse-engineer the definition: it’s a bill (a list) of materials (stuff). Specifically, it’s a list of everything that goes into making a product you sell, or what SAP calls a finished good. So far, so good. 

In SAP, the BOM lives in tables like MAST (which links a material and plant to its BOM) and STKO/STPO (the BOM header and line items). Pull those tables and you’ve got your list: material numbers, descriptions, quantities. Feels like a grocery list, right? Grab it and go. 

Except it’s never that simple. 

BOMs can be surprisingly powerful business tools. They tell you what types of materials are in a product, for example metal, plastic, packaging, chemicals, and how much of each. And if you join that BOM data to MARC (plant-level material data) or EINA/EINE (purchasing info records), you can start piecing together where each component comes from and what it costs. Suddenly your humble BOM is giving you lead times and production costs. Not bad for a list. 

But here’s where the rabbit hole starts. 

Many products aren’t just assembled from raw materials. They’re built from sub-components, each of which has its own BOM. That sub-component might have sub-sub-components. Which have their own components. You see where this is going. 

What you end up with is a multi-level BOM, basically  a tree structure that can go surprisingly deep. And here’s the kicker: SAP doesn’t store the depth of that tree anywhere obvious. There’s no clean field on MARA (the general material master table) or MARC that just says “this BOM is 4 levels deep.” You have to go discover that yourself. 

Throw in the fact that most manufacturers use centralized warehouses — meaning a component might be “sourced” from an internal storage location rather than directly from a vendor  and now you have to account for that routing too. A material might look like it comes from Plant B, but Plant B is just a distribution hub; the real source is a supplier three tiers up the chain. 

This is where recursive queries earn their keep. 

Think of a recursive query like a very disciplined copy-paste. You write your base query: grab the BOM items from STPO, join to MAST to get the parent material, pull sourcing logic from MARC or purchasing tables. Then you repeat that logic on its own output:  Level 1 becomes the input for Level 2, Level 2 feeds Level 3, and so on until you’ve walked the full tree. 

The catch? You have to decide how many levels to recurse. And since SAP won’t just tell you the answer, you’re left doing some detective work upfront — running exploratory queries, eyeballing the data, and making a call. It’s not glamorous, but it works. 

Manufacturing data is rarely flat. The sooner you embrace that, the faster you’ll stop being surprised by it.

Also – we’re here to help! Reach out and we can look at your process (in SAP or any other system) and help you find a way to get what you need out of it.

Leave a Reply

Discover more from Smart Scale Analytics

Subscribe now to keep reading and get access to the full archive.

Continue reading