MD05 — MRP List Display

MD05 displays the MRP list, the snapshot of stock and requirements exception messages that SAP wrote to the database when MRP last ran for a specific material and plant, or MRP area. It is not a live view. The numbers, dates, and exception codes on screen are exactly what the planning run calculated at that point in time, not what the situation is now. This is the one structural fact that explains most confusion about the transaction: a goods receipt posted five minutes after the MRP run, or a sales order entered afterward, will not appear in MD05 until MRP is run again. Consultants who expect MD05 to behave like MD04, recalculating on every call, end up chasing discrepancies that are simply the list being out of date rather than a data error.

Reached for when someone needs to know what MRP actually proposed and why, after the run finished, without triggering a fresh and potentially slow recalculation. MRP controllers use it during daily exception handling, reviewing exception messages such as rescheduling proposals or missing parts, typically via a collective planning result view, with MD05 used for the single material deep dive when something needs closer inspection. It is also the reference point when reconciling what MRP saw against what is true right now: pulling up MD05 and MD04 side by side to identify everything that changed between the run and the current moment, such as new orders, cancelled reservations, or goods movements. On S/4HANA, newer Fiori monitoring apps cover similar ground, but the GUI transaction remains the fastest single material check.

The sequence is short because MD05 is a display transaction with almost no configuration on the entry screen.

MD05 is display-only; it does not create or change data. Everything it reads was written earlier by the MRP run itself.

Pull MDKP filtered by the material and plant in question and check the creation date and time on the header record against the current date; a mismatch of hours or days confirms the list on screen is stale relative to whatever event is being investigated. Cross-check MDVM for the same material and plant to see whether a planning file entry currently exists; no entry means the material has not been queued for the next MRP run. Compare current stock in MARD or MARC against the quantities shown in the MDTB rows to quantify exactly how much has moved since the list was frozen.

MD05 continues to work unchanged on S/4HANA as a GUI transaction, reading the same underlying MRP list structures. S/4HANA adds Fiori based material coverage and stock requirements monitoring apps that present similar exception and coverage information with a different navigation model, aimed at planners who work primarily in the Fiori launchpad. Neither the underlying MRP run logic nor the static-versus-live distinction between the MRP list and the current stock/requirements list has changed.

Functional, owned by the MRP controller or PP consultant reviewing planning results. ABAP involvement is rare and limited to custom exception message logic or list layout enhancements. Basis involvement is limited to MRP run performance or background job failures at the planning run level, since MD05 itself only displays what already exists. A good handover states the material, plant, the MRP run date being questioned, and whether the concern is about the list itself or about a mismatch against current stock.

MD04 is the natural companion, showing the live version of the same stock and requirements situation for direct comparison against the frozen MD05 list. MD01 and MD02 are the transactions that generate the list MD05 displays, at plant level and material level respectively, and are the correct response when the list is stale. MD03 covers single item planning at a more granular level and is useful when isolating why one material's list looks wrong. Reviewing how planned orders convert into production orders through the standard order lifecycle rounds out the picture of what happens downstream of the exceptions seen in MD05.