MDTB table — MRP List Item Table (Cluster)

One row in MDTB represents a single MRP element line within a stored MRP list: a planned order, purchase requisition, reservation, sales order, or stock quantity as it existed at the point the last MRP run processed that material and plant. The row carries the date, quantity, and sign (requirement versus receipt) of that element, exactly as calculated during the planning run. It is not recalculated on display. The list it belongs to is generated by MRP and then persisted; MDTB is the body of that persisted list, while the header identifying which material, plant, and run it belongs to sits in MDKP. Because it is a snapshot, a row can be materially wrong the moment stock moves, an order is confirmed, or a new sales order is entered after the run completed.

Fields below are the ones consistently present in the cluster structure; exact technical names are listed with medium confidence given the cluster storage format and should be verified against the current structure definition before being hard-coded into a report.

MDTB is keyed to its header by material and plant, and each element line logically points back to the source document that generated it, even though the cluster storage does not enforce that as a normal foreign key.

MDTB is cluster-organized data, not a plain transparent table in every release, so a direct SELECT or a naive SE16 join across MATNR and WERKS can return nothing useful or fail outright depending on the storage form in the system being examined. Always restrict by MANDT, then by the exact MATNR and WERKS pair from MDKP, and treat the result as belonging to one specific MRP run, not to 'the material' in general. Never assume the rows are current; check the run date and time stamped on the MDKP header before drawing conclusions from any MDTB row.

Symptom: a planner insists the MRP list (MD05) shows a shortage that current stock overview does not. Pull the MDKP header for the material and plant to get the run timestamp, then compare the MDTB element dates and quantities against a fresh MD04 pull for the same material and plant. If the MDKP timestamp predates a known goods receipt or order change, the mismatch is explained: MDTB is stale, not wrong.

The classic MRP list concept, with results persisted in header/item cluster tables such as MDKP and MDTB, predates S/4HANA's move toward MRP Live, which is built to recalculate planning results efficiently in the database rather than rely solely on a stored snapshot. Depending on how MRP is run and which planning transactions are still in use, the classic list storage may still be populated for backward compatibility, but the operational emphasis on S/4HANA systems has shifted toward live re-evaluation. Any release-specific claim about whether MDTB is still written in a given system should be confirmed against that system rather than assumed.

The recurring mistake with this table is treating a frozen result as if it were live data, and the consequences compound from there.

The PP consultant or MRP controller who configured the planning run and interprets MRP lists owns questions about what an MDTB-based list shows. Basis gets involved only if the cluster storage itself cannot be read technically. Master data or supply chain planning owns the underlying material and stock data that made the run produce a given result.

MDKP is the header record identifying which material, plant, and MRP run the MDTB rows belong to. PLAF, RESB, and AFPO/AFKO are the live documents that individual MDTB element lines represent. The MRP list is generated by the MRP run transactions and displayed through the MRP list and stock/requirements list transactions; deleting or reorganizing old lists is typically done through the same planning transaction family.