SAP PP / M2D Interview Questions

A foundational tour of why demand-driven planning, MRP, and capacity checks exist, what business problems they solve, and how this topic fits into the broader PP learning path. Deep explanation: Demand Management, MRP, and Capacity Planning form the planning backbone of any manufacturing or distribution business running SAP. Before a single production order or purchase requisition is created, the business needs a disciplined way to answer three questions: what do we expect to sell or consume, what do we need to produce or procure to meet that expectation, and do we have the capacity (machines, work centers, labor) to execute the plan. This topic module exists to teach that chain end-to-end, rather than treating each piece (demand, MRP, capacity) as an isolated transaction skill. Business purpose: Without demand management, companies either overproduce (tying up cash in inventory) or underproduce (missing customer commitments). MRP exists to mechanically translate demand (independent requirements like sales forecasts or planned independent requirements, and dependent requirements driven by BOM explosion) into time-phased supply proposals - planned orders, purchase requisitions, or schedule lines. Capacity planning exists because MRP alone is capacity-infinite by default in many configurations; it will happily schedule ten orders on a single work center in the same hour unless capacity evaluation and leveling are applied. How the pieces connect: Demand Management (transaction family around independent requirements) feeds MRP as one of several requirement types. MRP (executed at plant or MRP area level) nets demand against stock, safety stock, and scheduled receipts, then explodes BOMs and routings to generate dependent requirements and supply elements. Those supply elements carry duration and work center assignments derived from routings, which capacity planning tools (capacity evaluation, capacity leveling) analyze against available capacity defined via work center capacities and shift sequences. This is why master data quality - BOMs, routings, work center capacities, planning strategies - is the prerequisite for reliable output from MRP and capacity; garbage master data produces technically correct but operationally useless proposals. Deployment context matters from day one. In ECC, this is executed through classic MRP transactions and optional integration to standalone APO for advanced planning. In S/4HANA on-premise/private cloud, MRP Live (using HANA-optimized processing) replaces classic MRP run performance characteristics, and Predictive MRP and advanced ATP concepts are more tightly embedded. In S/4HANA Public Cloud, configuration is delivered through the SAP Fiori-based configuration environment (SSCUI) with more standardized, restricted scope than on-premise IMG access. Where SAP PP/DS (Production Planning and Detailed Scheduling) is used - whether as an add-on in on-premise S/4HANA or via integration - detailed, finite-capacity scheduling becomes possible in a way classic MRP does not natively provide. What this parent topic will NOT do: it will not re-teach individual child-topic details like exact planning strategy configuration steps, individual MRP type behavior nuances, or PP/DS heuristic profiles - those live in dedicated child lessons. Instead, this orientation lesson establishes the mental model: demand signals in, netting and BOM/routing explosion in the middle, capacity evaluation as a checkpoint, and advanced planning (PP/DS, IBP integration) as the evolution path for organizations outstripping classic MRP's infinite-capacity assumptions. For a learner, the practical takeaway is sequencing: master data (materials, BOMs, routings, work centers) must be understood first, then demand management concepts, then MRP mechanics, then capacity evaluation, then advanced planning tools. Skipping ahead to MRP configuration without understanding demand management strategies is a common cause of confusion when planned independent requirements do not consume correctly or when unexpected planned orders appear. Recommended practices: • Always map planning strategies per material group before configuring MRP types • Validate master data quality (BOM, routing, work center capacity) before troubleshooting MRP output anomalies • Treat capacity evaluation as a mandatory review step, not an optional afterthought, in any MRP-driven planning cycle • Clarify deployment context (ECC vs S/4HANA on-premise vs public cloud vs PP/DS) before assuming any specific tool behavior • Sequence learning and implementation work in the order: master data, demand strategy, MRP, capacity, advanced planning Common mistakes to challenge: • Treating MRP as a single monolithic transaction rather than understanding it as netting plus BOM/routing explosion driven by upstream master data and demand strategy • Assuming capacity is automatically respected during standard MRP runs without explicit capacity evaluation or leveling steps • Ignoring planning strategy selection early in a project and discovering demand consumption problems only during integration testing • Confusing ECC classic MRP behavior with S/4HANA MRP Live pe

Introduces the core master data objects in Production Planning and explains why their quality and consistency determine the reliability of MRP, scheduling, execution, and costing. Deep explanation: Every SAP PP process — from demand planning through production order confirmation and costing — depends on a small set of master data objects being accurate, complete, and consistently maintained: the material master (especially MRP, work scheduling, and costing views), bills of material (BOM), work centers or resources, routings (or rate routings/master recipes in process industries), and production versions that link BOM and routing together for a specific plant and lot-size range. Why this matters in real projects: MRP explodes demand using the material master's MRP views and the BOM; if a BOM component is missing or has a wrong quantity, planning either overstates or understates dependent requirements, causing costly expediting or excess inventory. Similarly, if a work center's formulas for setup, machine, and labor time are wrong, capacity leveling and scheduling become unreliable, and standard costing (which reads routing/work center rates) produces inaccurate cost estimates. Because these objects are shared across MM, PP, QM, CO, and often SD/EWM, master data errors propagate across modules — a wrong valuation class in the material master can break goods movements and costing simultaneously. Design/implementation view: master data creation typically follows a lifecycle — material creation (basic data, then plant-specific views added incrementally), BOM creation (single-level, multi-level, or variant BOMs for configurable materials), work center or resource definition (capacities, formulas, cost center assignment), and routing creation (operations, sequence, standard values, control keys that drive costing/confirmation/PRT usage). Production versions tie a specific BOM alternative to a specific routing/rate routing, valid for a lot-size range and validity period — this is what MRP and production order creation actually select at runtime. Runtime flow: when MRP runs, it reads the material master's planning parameters (lot size, MRP type, procurement type), explodes the BOM via the selected production version, and schedules using routing lead times and work center capacities. When a production or process order is created, the system re-reads the production version to pull the current BOM and routing, generating order components and operations. Confirmations post against these operations and update capacity load; goods movements post against components per the BOM structure and update inventory/valuation. ECC vs S/4HANA: the underlying master data concepts are largely unchanged, but S/4HANA introduces the Material Master via the redesigned Manage Product Master UI (Fiori) alongside classic transactions, simplified data models (e.g., MARC/MARA underlying structures still exist but some views are consolidated in the UI), and tighter integration with PP/DS for advanced planning. In S/4HANA Cloud public edition, master data maintenance is done through Fiori apps with more constrained, pre-configured scope items, whereas private cloud/on-premise retain fuller classic configuration flexibility. This overview will guide you into deeper child topics covering each object and its configuration in detail. Recommended practices: • Establish a master data governance process with defined owners for material, BOM, work center, and routing objects • Use mass maintenance and validation reports before go-live to check for missing views, orphan BOMs, or unassigned production versions • Always maintain production versions explicitly rather than relying on automatic determination in complex environments • Align valuation classes, cost centers, and control keys across material master, work center, and routing to avoid costing discrepancies • Document plant-specific master data variations because behavior can differ per plant even for the same material Common mistakes to challenge: • Creating materials with only basic/plant views and forgetting MRP or costing views, causing MRP or costing run failures • Maintaining BOM component quantities inconsistent with the base quantity, leading to scaling errors • Assigning work centers to the wrong cost center, silently corrupting product costing • Not maintaining production versions, forcing MRP/order creation to fail or use inconsistent BOM-routing pairs • Copying materials without reviewing plant-specific parameters, propagating wrong MRP types or lot sizes Interview angle: Interviewers commonly probe whether a candidate understands that master data quality is a prerequisite for planning accuracy, not just data entry. Expect questions like: what happens if a production version is missing at order creation, how do BOM base quantity and component quantity interact in explosion, and how would you diagnose an MRP result that looks wrong — tracing back to master data versus configuration versus transactional data.

Learn what a production version is, why SAP requires it to link BOM and routing, and how it appears in the material master MRP4/Work Scheduling views. Deep explanation: A Production Version is a master data object in SAP PP that links a specific Bill of Material (BOM) alternative to a specific routing (or master recipe, in process industries) for a given material, plant, and validity period. It answers a fundamental manufacturing question: when this material is produced, which components (BOM) and which operations/resources (routing) should be used together? Without production versions, a material could theoretically have multiple BOM alternatives and multiple routing groups/counters, but nothing would explicitly tell the system which BOM goes with which routing. Production versions solve this ambiguity by creating an explicit, plant-specific pairing. This is essential because a company may produce the same material in different ways depending on volume, season, plant capability, or engineering change status - for example, a manual assembly line for low-volume runs and an automated line for high-volume runs, each with different component quantities (scrap allowances) or different operation sequences. Production versions are maintained on the material master, MRP4 view (Work Scheduling) tab, or via a dedicated production version screen. Each entry contains: a version number (up to 4 characters), a validity period (from/to dates), a lot size range (from lot size / to lot size) that determines which version is selected automatically by MRP based on the planned order quantity, the BOM usage and alternative BOM number, the task list type (routing, rate routing, or master recipe) with group and group counter, and optionally a production line (for repetitive manufacturing) or storage location for backflushing components. The production version is not just a planning convenience - it directly drives runtime behavior. When MRP creates a planned order, it evaluates active production versions for the material, checks the lot size range against the planned quantity, and checks validity dates against the requirement date. If exactly one version qualifies, it is assigned automatically. If multiple versions qualify, the system may pick based on a quota arrangement or require user selection depending on configuration. If no version qualifies, MRP can still create the planned order, but production order/process order conversion will fail or require manual version assignment, causing costed BOM explosion errors or missing routing errors on the shop floor. In Repetitive Manufacturing (REM), production versions are mandatory because REM planning tables and backflushing entirely rely on the version to determine the production line and the components to consume. In discrete manufacturing, production versions are technically optional in ECC for very simple setups, but SAP strongly recommends them, and in S/4HANA, production versions are effectively required for materials that will be planned by MRP Live and executed with modern Fiori apps, because several S/4HANA planning and execution transactions expect a valid, checked production version to exist. A critical prerequisite is that the production version must be checked and marked as usable. SAP provides a status field (with values like blank/not checked, 1/checked-execution allowed, 2/checked-error exists) that reflects whether the BOM-routing combination was validated (components exist, routing operations reference valid work centers, quantities are consistent). An unchecked or erroneous production version can still exist in the system but will cause failures downstream during order creation or costing. Recommended practices: • Always define non-overlapping, contiguous lot size ranges across production versions for the same material to guarantee deterministic MRP selection. • Run and clear the production version consistency check immediately after creating or changing BOM/routing links, before relying on MRP results. • Use meaningful version numbering conventions (e.g., 0001 for primary line, 0002 for backup line) documented in a master data governance guide. • Coordinate production version creation with BOM and routing teams as a single master data unit rather than three disconnected activities. • Validate production versions per plant during rollouts; do not assume they copy automatically with material extension. Common mistakes to challenge: • Creating a BOM alternative and a routing but forgetting to link them via a production version, leading to MRP creating planned orders that later fail conversion to production orders. • Leaving overlapping or gapped lot size ranges across multiple production versions, causing MRP to either pick an unintended version or fail to find any valid version for certain order quantities. • Not running the production version check (status field) after creating or changing BOM/routing links, so an invalid combination sits unnoticed until shop floor execution fails. • Assuming production versions are optional in S/4HANA the same way they were in older ECC discrete manufacturing setups, then hitting errors in MRP Live or Fiori execution

Introduces why process industries need a different manufacturing model than discrete PP, and explains the core master data objects: master recipe, resource, and material list, along with the process order. Deep explanation: Discrete manufacturing (assembling cars, electronics) uses bills of material and routings tied tightly to individual materials and operations performed by machines or labor. Process manufacturing (chemicals, pharma, food, beverage) is different: production is defined by formulas or recipes that describe proportions of ingredients, phases of a continuous or batch process (heating, mixing, reacting, cooling), and quality-critical parameters like temperature, pH, or pressure that must be recorded, not just quantities consumed. SAP's PP-PI (Production Planning for Process Industries) component was built specifically to model this reality, and it remains conceptually present, though technically converged, in S/4HANA. The three foundational master data objects are the master recipe, the resource, and the material list (formula). The material list is the process-industry equivalent of a bill of material: it lists the ingredients (components) and their quantities or percentages needed to produce a batch of the finished product, and it can include by-products and co-products naturally, which is common in chemical reactions. The resource is broader than a discrete work center: resources model not just machines but process units, storage tanks, or lines with capacities, and they carry standard values for process instructions like duration or rates. The master recipe ties these together: it defines the sequence of phases and operations, links to resources responsible for executing them, references the material list for component consumption, and embeds process instructions and characteristics that will later print on a Process Instruction Sheet (PI sheet) used by the plant operator or captured through automation interfaces. At runtime, when a process order is created (either manually or from planned orders via MRP), the system copies the master recipe, material list, and resource assignments into the order, similar to how a discrete production order copies a routing and BOM. The process order then carries phases (not just operations) as the level at which confirmations, goods movements, and PI sheet data are recorded. A phase is a self-contained unit of work with its own control key that determines whether it triggers scheduling, costing, or PI sheet generation. This phase-based structure is a hallmark of process manufacturing and is the reason many QM inspection lots and batch determination logics attach at the phase level rather than the header. Why this matters for a consultant: process industries operate under tighter regulatory and quality obligations (batch genealogy, electronic batch records, environmental limits) than typical discrete manufacturing, so incorrect recipe design or resource assignment can cause not just planning inefficiency but compliance failures. Understanding the recipe-resource-material list triangle is the prerequisite for every later topic in this module: PI sheets, batch management integration, process order confirmation, and costing by phase. In S/4HANA, the underlying data model for PP-PI has been harmonized under the umbrella of production planning, and the transactions and master data concepts remain largely familiar to ECC consultants, though embedded analytics and Fiori apps provide newer ways to monitor process orders. Consultants should always verify with the client's specific S/4HANA release which classic transactions are still supported versus redirected to Fiori equivalents, since SAP has been progressively simplifying and, in some areas, restricting classic GUI transactions in newer public cloud releases. Recommended practices: • Design master recipes with phases that reflect real physical process steps to support meaningful confirmations and quality checks. • Use resources rather than simple work centers when process-specific capacity or standard values (e.g., batch cycle time) matter. • Keep material lists aligned with actual chemistry/formulation documentation to avoid discrepancies between engineering and SAP master data. • Validate control key settings on every phase before moving a recipe to production status. Common mistakes to challenge: • Treating the material list purely as a BOM copy without accounting for co-products and by-products particular to the reaction. • Assigning all phases to a single generic resource, losing the ability to schedule and cost distinct process steps separately. • Forgetting to set the correct control key on phases, which then fails to trigger PI sheet generation or milestone confirmation. • Confusing routing operations (discrete) with recipe phases (process) when consultants move between projects, leading to incorrect assumptions about confirmation logic. Interview angle: Interviewers often ask candidates to explain the difference between a BOM/routing pair and a material list/master recipe pair, and why phases exist instead of operations. A strong answer highlights that phases carry control keys enabling PI s

Before accepting a split, evaluate whether the split preserves correct scheduling (each partial order gets independently scheduled dates based on component availability), whether cost collection and settlement rules apply consistently across resulting orders, and whether the original order's reservations, confirmations, and any partial goods movements are correctly transferred. Tradeoffs include increased administrative overhead (multiple orders to track), potential fragmentation of costing/variance reporting, and risk of double-counting if partial confirmations already occurred before the split. Validate settlement profile behavior on each resulting order and confirm capacity leveling is re-run.

I'd check the scheduling parameters for the order type/plant combination, specifically whether automatic scheduling considers replenishment lead time or in-house production time for staged components, and whether the order's basic dates were generated with backward vs. forward scheduling causing tight start dates. I'd also review the supply area lead time in the control cycle or storage location assignment feeding the operation, and confirm that reservation availability dates align with the operation's earliest start rather than the order's basic start date.

First check PP/DS application log and CDS-based monitoring apps for heuristic run failures or timeouts, then verify the integration model (CIF) queues (SMQ1/SMQ2) aren't stuck, which often causes backlog buildup. Review BTP Integration Suite iFlow logs for message failures affecting supplier confirmations feeding back into PP/DS. Reassess whether migrated master data objects (e.g., PPDS-specific settings) were correctly transferred, since incomplete migration objects can cause heuristics to skip orders.

Clean Core avoids custom code in S/4HANA by using standard CIF-based or SAP-delivered IBP integration content (CDS-based extraction, standard APIs) for master and transactional data exchange with MM (material master, stock, batches). Any needed extensions are built via in-app or side-by-side BTP extensibility, keeping the S/4HANA core untouched and upgrade-safe, rather than modifying standard MM tables or function modules.

I check whether the material has a released standard cost estimate for the relevant plant and costing version, since order costing pulls from the current standard per the valuation variant's strategy sequence. I verify the costing variant's valuation variant strategy order, check if a marked-but-not-released estimate exists, and confirm the order's costing lot size and date don't fall outside the validity period. I also review whether plant-specific pricing strategy overrides were introduced regionally without updating the shared variant.

Architect capacity leveling to run outside peak MRP Live windows, ensure work center capacity categories distinguish production versus maintenance demand where feasible, and use finite scheduling selectively rather than for the full horizon to limit computation load. In Public Cloud, rely on standard scope items for capacity evaluation since custom code is restricted, and monitor job runtime via application job monitoring to detect performance degradation as order volume grows.

Establish monitoring via BD87/interface monitoring dashboards for failed IDocs affecting PM-triggered reservations or refurbishment orders feeding MRP, set alerting thresholds for error IDoc counts, and enforce a control that MRP Live runs are gated or flagged when critical PM-related IDocs remain unprocessed above a defined age. Include reconciliation checks comparing PM demand records against ACDOCA-independent MRP tables to catch silent gaps, and define escalation and reprocessing SLAs.

Start by comparing the settlement documents (CO document type) against the resulting FI/Universal Journal postings using the order number as the common key, checking BKPF/ACDOCA for the settlement posting and confirming the PA transfer structure and cost element assignment used. Check for postings that bypassed settlement, such as manual FI adjustments to the order's cost center or account, and verify no parallel currency or ledger-specific postings were excluded from the comparison report. Also confirm the reporting period and fiscal year variant alignment between CO and FI views.