MD04 — Stock/Requirements List Display

MD04 shows the stock/requirements list: a chronological line-up of a material's warehouse stock against every open requirement and every open receipt for a plant or MRP area. Requirements include sales orders, reservations, dependent requirements from BOMs, and forecast. Receipts include purchase requisitions, purchase orders, planned orders, and production or process orders. The one structural fact that explains most confusion: MD04 is not reading a stored MRP result table, it is assembling the list dynamically at the moment the screen opens, pulling from the live transactional tables behind sales, purchasing and production. There is no 'MD04 table' to query directly for the exact list a user saw. A second MD04 run five minutes later on the same material can show a different picture purely because a sales order was entered or a goods receipt posted in between.

MD04 sits downstream of the MRP run (MD01 or MD02) and is the standard place to check whether that run produced sensible results, and downstream of any transaction that consumes or creates supply or demand for a material: sales order entry, goods movements, purchase order creation, production order release. Planners open it several times a day as their working cockpit; consultants open it during an incident to see, at a glance, whether a shortage, a duplicate order proposal, or a missing planned order is real or a display artifact. In S/4HANA the equivalent Fiori app covers the same use case for planners who work from the launchpad, but MD04 remains the faster tool for a consultant doing root-cause work because it exposes exception messages and MRP elements with less navigation than the app.

To confirm what MD04 is actually built from for a given material and plant, check the source tables directly rather than trusting the screen a second time. Query MDVM on material and plant to confirm the planning file entry exists and its change indicator; an entry stuck without the net-change flag means MRP has not picked it up since the last relevant change. Cross-check PLAF for open planned orders and RESB for reservations on the same material-plant, filtering on the relevant MRP element status, and compare counts against what the MD04 screen actually rendered. A mismatch between what these tables hold and what MD04 displayed usually points to a filter setting or an MRP area that was not selected.

MD04 still exists and functions the same way on S/4HANA; the screen layout, exception codes, and drill-down behavior are essentially unchanged for a consultant working an incident. The underlying selection logic was rebuilt against the S/4HANA data model rather than the classic pooled MRP tables, which mainly affects performance on large materials, not the diagnostic approach. A Fiori app equivalent exists for planners working from the launchpad, covering the same stock and requirements view, but it does not replace MD04 for root-cause work since MD04 still exposes the raw MRP elements more directly.

This is functional territory, owned by the PP or MM planner and the consultant supporting the planning process. ABAP involvement is rare and limited to custom exception logic or performance issues on the list generation; Basis involvement is limited to authorization objects for plant or MRP area. A good handover states the exact material-plant (or MRP area), the timestamp the screen was viewed, whether the planning file entry was checked, and whether the discrepancy survived a refresh.

MD01 and MD02 are the transactions that actually generate the planned orders and requisitions MD04 displays, so an MD04 anomaly traces back to how MRP was last run there. MD05 is the single-item, single-level MRP list variant useful when a full multi-level run is too heavy for a quick check. MD61 and MD62 matter when the demand side traces back to a planning strategy or independent requirement rather than a firm sales order. CO09 and CS01 to CS13 are relevant when the missing supply element turns out to be a BOM or component issue rather than an MRP timing issue.