MD01 — Total Planning Run for a Plant
MD01 runs MRP for every material in a plant in one pass, exploding BOMs and processing materials in low-level code order to generate planned orders and purchase requisitions. It is the plant-wide counterpart to MD02 (single-item, multi-level) and is normally scheduled as a background job because a full run against a large plant can take hours.
This page covers the total planning run transaction MD01, what it actually processes and in what sequence, the tables its results land in, and the recurring failure patterns consultants see when a run does not produce the expected planned orders or requisitions. It also covers the S/4HANA MRP Live equivalent and who owns which part of a failed run.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,122 words
Purpose
MD01 triggers a total planning run: MRP for all materials in a plant, not just one. Materials are processed in low-level code order, so a finished good is only planned after all its component low-level codes have been recalculated correctly, otherwise the run plans in the wrong sequence and shortages surface late. The structural fact that explains most confusion: MD01 respects the planning file entry (the net-change flag) unless the run is set to regenerative. If a material's planning file entry was never set, or was cleared by a prior run, MD01 silently skips it, and the material simply does not get replanned even though its requirements changed.
When it is used
MD01 sits in the recurring MRP cycle, typically run overnight or on a fixed schedule after independent requirements are loaded through MD61 or MD62 and after any BOM or routing changes have propagated. Planners and PP consultants reach for MD01 when the whole plant needs recalculating, for example after a demand plan reload, a large BOM restructuring, or a lot-size policy change affecting many materials. For troubleshooting a single material's planning result, MD02 or MD03 is the right tool, not MD01, because rerunning the whole plant to test one material wastes time and risks disturbing other materials' firmed elements.
How to use it in practice
- Enter the plant to be planned.
- Choose the processing key: NETCH for net change (only materials with a planning file entry), NETPL for net change in planning horizon, or NEUPL for regenerative (every material, regardless of change flag).
- Set the create purchase requisition indicator and delivery schedule indicator for externally procured materials.
- Set the MRP list indicator so exception messages are retained for review.
- Choose planning mode: 1 (adapt planning data, keep firmed elements), 2 (re-explode BOM/routing), or 3 (delete and recreate).
- Set the scheduling indicator (basic dates only, or lead time scheduling).
- Execute online for a quick test on a small plant, or schedule as a background job for production volumes.
Key data objects
- PLAF - planned orders created or updated by the run for in-house produced materials.
- EBAN - purchase requisitions generated for externally procured materials, with the requisition tied back to the triggering requirement.
- MDKP - the MRP document header per material and plant, holding the low-level code used, the run date, and pointers into the detail line items.
- MDTB - the MRP table entries linked to MDKP, carrying the individual requirement and receipt elements and any exception message numbers raised during the run.
How to prove it in the data
To confirm a run actually touched a given material, check MDKP filtered on material and plant and compare the stored run date field against the expected schedule date; if the date is stale, the material was skipped, not replanned with no result. Cross-check MDTB for the same MRP document to see whether exception messages were raised. Then check PLAF filtered on material, plant, and creation date to see whether a planned order was actually created in that run window, and EBAN filtered on material and creation date for the purchasing side.
ECC vs S/4HANA
MD01 still exists and behaves the same on S/4HANA, but SAP's recommended path is MRP Live, run through MD01N or the corresponding Fiori app for scheduling a total planning run. MRP Live pushes the net requirements calculation into the database layer and processes materials in parallel with less ABAP-layer overhead, which matters directly for the runtime pitfall above. The classic MD04 stock/requirements list view has a Fiori equivalent for material coverage that reads the same underlying planning result.
Common pitfalls and how to diagnose them
- Runtime and job failure: a plant-wide run touching thousands of materials can exceed background job time limits or get killed. Check SM37 for the job status and step duration before assuming the run failed logically. NEUPL (regenerative) is far slower than NETCH; confirm which processing key was actually used before diagnosing anything else.
- Material silently skipped: the most common complaint is 'MRP did not react to the change.' Before touching configuration, check whether the material's planning file entry (the net-change flag) was set. A material whose requirement changed outside a monitored transaction, or whose flag was reset by a prior successful run, will not be replanned by NETCH.
- Missing or stale master data: exception messages in MDTB pointing to no BOM found, no routing found, or MRP type not maintained mean the material was evaluated but produced no proposal. Check the material master MRP views and the BOM/routing status before rerunning.
- Low-level code out of date: if BOM structures changed recently and low-level codes were not recalculated, MD01 plans components before their parent's requirement is even known, leaving apparent shortages the run should have resolved. Recalculating low-level codes fixes the sequencing, not rerunning MD01 again.
- Firmed elements ignored: planned orders or purchase requisitions already firmed are deliberately left untouched by MD01 in planning mode 1. A planner expecting MD01 to 'fix' a firmed order is looking at the wrong lever; the fix is in the firming logic or a manual change, not another MRP run.
- Locking during parallel processing: a total run using parallel work processes can hold locks on materials being changed elsewhere at the same time, producing enqueue errors in other transactions. This is a scheduling conflict, not a data error, and resolving it means moving the run window, not adjusting master data.
Whose problem this is
Functional PP owns the processing key choice, planning mode, and master data (MRP type, lot size, BOM/routing status) that determine what the run does with each material. Basis owns background job scheduling, parallel work process allocation, and runtime tuning. A clean handover for a failed or incomplete run includes the job log, the plant and processing key used, and the specific materials with stale MRP document dates or exception messages.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/md01ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.