MD02 — MRP Single-Item Multi-Level Planning Run

MD02 triggers requirements planning for a single material and explodes its bill of material down through every level beneath it in one pass. It nets existing stock, open purchase orders, and open production orders against demand, and generates planned orders or purchase requisitions to cover the shortfall at each level. The structural fact that causes most confusion: MD02 is scoped to the material entered and its dependents only. It does not touch sibling materials that happen to share the same component, and it does not re-net requirements plant-wide. Two finished products consuming the same raw material will each need their own MD02 run, or a total planning run through MD01, before the combined requirement on that shared component is correctly reflected. Running MD02 on one and assuming the other has been recalculated is the single most common misunderstanding of this transaction.

MD02 is reached for after a localized demand change on one specific material - a new sales order line, a forecast override, an engineering change on a BOM, a converted planned order that frees up capacity - where running a full plant MRP through MD01 would be disproportionate and slow. It is also the standard tool for simulating the downstream effect of a single change before committing to a plant-wide run, and for troubleshooting why one material shows a shortage on the stock/requirements list. It is not the tool for routine nightly or weekly planning cycles; that is MD01 or a background-scheduled total run. In S/4HANA the same logic is exposed through MRP Live for mass runs and through Fiori monitoring apps for review, but MD02 remains the standard single-item execution transaction, particularly for ad hoc dialog runs during incident resolution.

Check PLAF filtered by material and plant, sorting on creation date and time, to see whether new or changed planned orders exist for the run window in question. Cross-check EBAN on the same material and plant to see whether a purchase requisition was generated instead of a planned order, which points at a procurement type or special procurement key issue rather than a run failure. Compare the timestamp on both against the MRP run's log timestamp (available from the run's own log display or the background job log) to confirm the run actually touched the material rather than exiting early on a planning file check.

MD02 behaves the same on S/4HANA as on ECC; the netting and BOM explosion logic is unchanged. What is new is MRP Live, which replaces the total planning run for mass processing and runs substantially faster on the HANA database, and Fiori monitoring apps that surface the same planned orders and requisitions for review without requiring the classic MRP list screen. MD02 itself remains available and is still the standard tool for single-material dialog runs during troubleshooting.

This is functional PP/MRP controller territory in almost every case; the settings that determine outcome - MRP type, lot size, procurement type, special procurement key, BOM validity, planning file status - are master data and configuration, not code. Basis involvement is limited to background job scheduling or performance. A good handover states the material, plant, the exact parameters used on the initial screen, the run's log output, and whether the planning file entry was set beforehand.

MD04 is the first stop to see the actual stock/requirements situation the run produced or failed to produce. MD01 and MD03 clarify the scope question directly - MD01 for plant-wide total planning, MD03 for single-item single-level, both useful for isolating whether a problem is specific to MD02's multi-level scope. MD05 gives the evaluation view of a completed run. CS02 is worth checking whenever the explosion stops early, since an incorrect BOM usage, alternative, or validity date on the component structure is a frequent root cause mistaken for an MRP bug.