PLAF table — PLAF Planned Order Table in PP

Each row in PLAF is one planned order: a proposal generated by MRP (or created manually) representing a quantity of a material that needs to be produced or procured by a certain date at a certain plant. Planned orders are the softest layer of supply in the PP data model, sitting between the MRP element list and a firm production order or purchase requisition. A planned order carries a quantity, a start and finish date, the responsible MRP controller, and the procurement type that determines whether it will convert into an in-house production order or an external purchase requisition. It does not carry a full bill of material explosion or operation list as static data; the order's components and operations are only materialized when the order is created or converted, and are found through the order's internal planning numbers rather than stored flat in PLAF itself.

PLAF is client-dependent; always restrict on MANDT alongside the real filter. Never select on PLAF without at least plant (PWWRK) and material (MATNR), and ideally a date range on GSTRP or GLTRP, because a single MRP run across a busy plant can generate thousands of planned orders in one pass and an unrestricted select against this table on a production system is a real load risk. PLNUM is the only field guaranteed to be unique and cheap to filter on if it is already known from another document; everything else benefits from a compound restriction. Do not assume a planned order still exists just because it was reported in yesterday's MRP list — MRP deletes and regenerates planned orders on every run, so PLAF reflects only the current planning situation, not history.

To confirm a reported shortage is being covered by a planned order rather than a firm order, select PLAF where MATNR equals the material and PWWRK equals the plant, restricted to GLTRP within the relevant horizon. If a row returns, check BESKZ to see whether it is heading toward production or purchasing, and cross-check RESB on the same PLNUM to see whether components have already been reserved. If no row exists, the shortage is not currently covered by any planned supply and the next place to look is the MRP list itself, not PLAF.

Planned orders remain a live PP object in S/4HANA and PLAF continues to be the table behind them; there is no compatibility-view replacement because the planned order concept itself was not restructured the way production order or BOM tables were. MRP Live writes and deletes planned orders through the same underlying object, so consultants moving from ECC find PLAF behaves the same way functionally, even though the MRP execution engine generating those rows is different from the classic MRP run.

Questions about why a planned order exists, its dates, or its procurement type belong to the PP/MRP consultant who owns the material's MRP settings and lot-sizing configuration. Questions about the reservation quantities it generates belong to whoever owns inventory management and availability checking, since that consumption logic sits outside PLAF itself.

RESB holds the component reservations a planned order generates and is written automatically as a side effect of MRP creating the order. AFVC holds the operation data copied in from the routing when the order picks up scheduling information. Conversion of a planned order into a firm order is done through the standard planned order conversion transactions in PP, at which point the relevant data moves into AFKO/AFPO for production orders or into a purchase requisition outside the PP tables entirely.