MD03 — Single-Item Single-Level MRP Run

MD03 executes MRP for exactly one material in exactly one plant, and it stops at that material's own level. It reads open requirements (sales orders, reservations, dependent requirements already posted against it, forecast) and generates or updates planned orders, purchase requisitions or delivery schedule lines to cover the net requirement. The structural fact that explains almost every support ticket on this transaction: MD03 is single-level. It does not trigger planning for the components in the material's BOM. A consultant runs MD03 on a finished good expecting the semi-finished and raw material levels underneath to get replanned in the same run, sees no new planned orders on the children, and assumes MRP is broken. It is not broken; MD03 was simply never designed to explode further than the one material entered.

MD03 is a testing and troubleshooting tool, not a production planning run. It gets used when a consultant needs to isolate the behavior of one material after a master data change, a lot size adjustment, an MRP type change, or a special procurement key change, without disturbing the plant's full planning picture. It is also used to reproduce a reported symptom on one material before deciding whether the fix needs to be tested plant-wide. For actual production planning cycles, the plant runs MD01 (total planning) or MD02 (single item, multi-level, which does explode through the BOM) on a schedule. MD04 and MD05 are read-only, used to inspect the result MD03 produced, not to generate it.

In SE16 on PLAF, filter by material and plant and compare the creation timestamp field against the time the MD03 run was executed; a run that produced no new rows and no changed rows confirms 'no change detected', not a failed run. Cross-check EBAN filtered on the same material for requisitions with a matching creation date. If the run appears to have done nothing at all, check the planning file entry for the material and plant (visible via the planning file maintenance transactions) before assuming a data problem, since a missing or stale planning file entry is the most common reason MD03 reports no requirement to plan.

MD03 exists unchanged in the S/4HANA GUI, with the same fields and the same single-level restriction. The Fiori apps for MRP (typically framed around scheduling and monitoring a plant-wide run) map more closely to MD01's total planning use case than to MD03's single-item diagnostic use case; there is no dedicated Fiori app that replaces the single-material, single-level test run. Consultants doing targeted troubleshooting on one material still reach for MD03 in the GUI on S/4HANA systems.

This is functional PP or MM territory, owned by the material planner or the consultant configuring MRP types, lot sizes and procurement parameters. ABAP gets involved only if a custom requirements exit or BAdI is suspected of altering the net requirement calculation. A clean handover states the material and plant tested, the processing key and planning mode used, the exact timestamp of the run, and whether the planning file entry was confirmed beforehand.

MD02 is the natural next stop for anyone who ran MD03 and then needed the BOM components replanned as well, since it performs the same logic but explodes multi-level. MD01 is the production-cycle equivalent run against the whole plant rather than one material. MD04 and MD05 are the read-only views to inspect exactly what MD03 produced, including MRP elements and exception messages, before deciding whether the run behaved correctly. MD61 and MD62 are worth understanding separately since planned independent requirements maintained there are frequently the demand input that MD03 is reacting to.