STAS table — STAS - BOM Item to Operation Allocation Table
STAS stores the assignment between a BOM item and a task list (routing) operation, using an item allocation number that also appears on the BOM item and on the operation. It answers the question 'at which operation is this component consumed', which drives component staging, backflushing and pick list generation on the production order.
STAS is the master-data cross table that links a BOM item to the routing operation where it is consumed, at the planning level rather than the order level. This page covers the fields that matter, how the join actually works through the shared allocation number, and the recurring mistakes made when reading this table to explain component-to-operation problems on production orders.
Published 16 Sept 2026· 962 words
What it stores
One row represents a single allocation of a BOM item to a group of task list operations for a specific BOM alternative, expressed through a shared allocation number rather than a direct foreign key to the operation table. The assignment lives at the master data level: it is maintained once against a BOM alternative and a task list group, and it is what the system uses at order creation time to decide which operation a reservation line should be tied to. STAS does not contain order data and does not contain quantities; it is purely a linking record between BOM structure and routing structure, and it is subject to engineering change management like the BOM and routing records it connects.
Key fields
- MANDT - client
- STLTY - BOM category, for example M for a material BOM
- STLNR - internal BOM number
- STLAL - BOM alternative
- STLKN - internal BOM item node number, links back to the BOM item record
- ZUONR - item allocation number, the shared value that also appears on the routing operation and identifies which operation the component belongs to
- AENNR - change number, present because item allocation is change-number-controlled like the BOM and routing it references
- LKENZ - deletion indicator on the allocation record
How it joins the data model
- STAS-STLTY/STLNR/STLAL/STLKN = STPO-STLTY/STLNR/STLAL/STLKN to get the BOM item text, quantity and component material
- STAS-ZUONR = PLPO-ZUONR to identify the operation the component is allocated to, within the routing group tied to the same BOM alternative
- STAS-STLNR/STLAL joins to MAST-STLNR/STLAL to find which material and plant use this BOM alternative
- STAS-STLTY/STLNR joins to STKO-STLTY/STLNR for the BOM header
- the resolved allocation is what the order build reads into RESB-VORNR when the reservation line is created for the production order
How to read it safely
MANDT is mandatory as always. Never select on STAS without at least STLTY, STLNR and STLAL, since the table is unindexed for anything narrower and a plant-wide scan against it is expensive. ZUONR is a text field, not numeric, and it is compared as an exact string against PLPO-ZUONR, so leading zeros, spaces or case differences between the BOM side and the routing side produce a silent non-match rather than an error. Filter LKENZ blank unless the deletion history itself is the question. If a change number is involved, restrict by validity date or you will read an allocation that is not yet effective or was superseded.
How to prove it in the data
Symptom: a component is being staged against the wrong operation, or the pick list groups it under 'no operation assigned'. Read STPO for the BOM item to get STLKN and confirm an entry exists in STAS for that STLTY/STLNR/STLAL/STLKN combination. If none exists, the item was never allocated and defaults to the first operation. If a row exists, take its ZUONR and look it up in PLPO for the same task list group; a mismatch or a ZUONR that does not exist on any operation in that group explains the misrouting.
ECC vs S/4HANA
STAS is retained in S/4HANA with the same structure; there is no compatibility view redesign comparable to the material master or classification tables. The item-allocation mechanism between BOM and routing was not restructured as part of the S/4HANA data model simplification, so lookups and joins written against STAS on ECC continue to work unchanged on S/4HANA.
Common pitfalls
- Treating a missing STAS row as an error: an unallocated component is valid and simply defaults to the first operation of the routing, it is not a data corruption
- Reading STAS as if it were order-level data: it holds the planning-level assignment only, the actual operation on a released order comes from RESB-VORNR, which is set at order creation and can diverge from STAS if the order routing was changed manually afterward
- Ignoring the BOM alternative: an allocation exists only for the specific STLAL it was maintained against, so checking the wrong alternative shows no allocation even though one exists for the alternative actually in use
- Ignoring change number effectivity and reading a row that is not valid on the date in question, which leads to blaming the wrong operation for a staging problem
- Assuming ZUONR is numeric and comparing it loosely; it is compared as text and a trailing space or a different number of leading zeros between the BOM item and the operation breaks the match without any warning
- Forgetting the LKENZ deletion flag and counting deleted allocation rows as active
Whose problem this is
Item allocation is maintained by whoever owns routing maintenance, usually a production planning or work scheduling analyst working through the routing transaction's item assignment tab, in coordination with whoever owns the BOM in engineering or plant maintenance master data. A mismatch is a master data configuration question, not a basis or interface question.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/stasERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.