Why MRP Exists: Business Purpose and Core Logic
Understand what problem MRP solves, how net requirements calculation works conceptually, and what master data drives the planning run.
Explanation
Material Requirements Planning exists to answer one recurring operational question: what do we need to procure or produce, how much, and by when, so that demand is satisfied without excess inventory or stockouts. Before MRP became standard in ERP systems, planners manually reconciled sales forecasts against stock levels and open orders using spreadsheets, which was slow and error-prone at scale. SAP MRP automates this by running a net requirements calculation for every relevant material: it looks at gross requirements (independent demand like sales orders or forecasts, plus dependent demand from higher-level bills of material) and nets them against available stock, safety stock, and existing receipts (open purchase orders, production orders, purchase requisitions already in the system). If the result is a shortage, MRP creates a procurement proposal - a planned order for in-house production or a purchase requisition/scheduling agreement release for externally procured materials. The planning run operates against master data that must be set up correctly for results to be trustworthy. The material master MRP views (MRP 1-4 in classic transactions) carry the MRP type, lot size, procurement type, planning strategy, and scheduling parameters. The plant-specific data determines whether a material is planned at all (MRP type ND means no planning). Bill of Material and routing/work center data drive dependent requirements explosion and lead time scheduling for in-house produced materials. Without an accurate BOM, MRP either fails to create dependent requirements for components or creates incorrect quantities, which cascades into wrong purchase requisitions for raw materials. MRP runs at the plant level and processes materials in a low-level code sequence - meaning finished goods are planned first, then MRP explodes their BOMs to create dependent requirements for components, which are planned next, cascading down to raw materials. This sequencing is critical: if it were reversed, component planning would run before knowing what quantity of parent material is actually needed. The output of MRP is not a final commitment - planned orders and purchase requisitions are proposals that a planner reviews, adjusts, and converts (planned order to production order, purchase requisition to purchase order). This human-in-the-loop step exists because MRP works from clean mathematical logic but cannot see everything - a planner might know a supplier is late, a machine is down, or a customer priority has shifted, none of which MRP inherently knows unless that information is reflected in the system (e.g., via a fixed receipt date or a firmed order). A foundational concept beginners must grasp is the distinction between independent requirements (demand not derived from another material, e.g., sales orders or forecast) and dependent requirements (demand derived from a BOM explosion of a parent item's planned or production order). This distinction underlies almost every troubleshooting scenario in MRP - if dependent requirements look wrong, the root cause is almost always in the parent's order, BOM, or planning strategy, not in the component's own master data.
Real project scenario
A newly implemented plant went live with MRP but planners noticed that raw material purchase requisitions were not being generated even though finished goods planned orders existed. Root cause analysis showed the BOM items for the raw materials were marked with a deletion flag from a data load error, so no dependent requirements were passed down. The fix required correcting the BOM and rerunning MRP for the affected finished goods, which then correctly cascaded dependent requirements to the components.
Common mistakes
• Assuming MRP type ND (no planning) materials will still generate proposals - they are excluded entirely from net requirements calculation. • Confusing independent requirements (sales orders, forecast) with dependent requirements (derived from BOM explosion) when troubleshooting missing demand. • Expecting MRP output (planned orders, purchase requisitions) to be final and automatically executed without planner review and conversion. • Not checking BOM validity dates and status, which silently prevents dependent requirement explosion even though the finished good plans correctly. • Ignoring low-level code sequencing and assuming materials plan independently of their BOM hierarchy position.
Best practices
• Always verify MRP type and procurement type on the material master before assuming a planning run should generate proposals. • Validate BOM status and validity dates as part of new material or plant setup checklists. • Educate planners that MRP proposals are recommendations, not commitments, and firmed/fixed orders should be used to protect confirmed executions from being changed by subsequent MRP runs. • Document the low-level code logic in training materials so planners understand why component shortages sometimes only appear after a parent item run.
Interview angle
Interviewers commonly ask candidates to explain net requirements calculation in plain terms and to distinguish independent versus dependent requirements with a concrete example. A strong answer describes the netting formula (gross requirements minus available stock and receipts, plus safety stock considerations) and explains why low-level code sequencing matters for multi-level BOMs. Be ready to explain why MRP output requires planner conversion rather than being auto-executed.