RESB table — RESB Reservation and Dependent Requirements Table

One row in RESB represents a single reserved or dependent requirement for one material at one plant, tied back to a source object such as a production order operation, a planned order, a maintenance order, a network activity, or a cost center withdrawal. The row carries the required quantity, the date the requirement is needed, and how much of it has already been withdrawn against goods issue. RESB is written the moment a production order is created or released (component determination from the BOM), and it is updated as goods issues post against the order. It does not record the goods movement itself, only the requirement and the running withdrawal total; the movement history sits elsewhere.

Always restrict on MANDT plus at least one of WERKS, MATNR, or AUFNR before running a selection; RESB accumulates one row per component per order across the entire order history and an unrestricted select on a live system can run for minutes. If the question is order-specific, filter on AUFNR first, since that index path is fast and narrow. If the question is material-specific across many orders, WERKS plus MATNR plus a BDTER date range is the workable combination. Do not select on BDMNG or ENMNG as filter criteria; they are not indexed and every full-table scan attempt on them will be slow.

Symptom: a production order component appears to still be open for goods issue even though the order is technically complete. Select RESB where AUFNR equals the order number, review each RSPOS line for BDMNG versus ENMNG, and check XLOEK and KZEAR on the same row. A line with BDMNG greater than ENMNG but KZEAR set or XLOEK set is closed by flag despite the apparent quantity gap, which is the actual explanation, not a posting failure.

RESB remains a physical, actively populated table in S/4HANA; there is no wholesale replacement of it. Component reservation logic for production orders and planned orders still writes to it the same way it did in ECC. Newer Fiori-based MRP and order-monitoring apps read from CDS views layered on top of RESB and related tables for reporting purposes, but the underlying table structure and the fields a consultant relies on for debugging component availability are unchanged.

The PP consultant owns the interpretation of reservation logic, component determination and final-issue flags. The MM or warehouse team owns the actual goods issue posting that updates ENMNG. Basis gets involved only when an unrestricted RESB read causes a performance problem on a shared system.

AFKO and AFPO hold the production order header and item that RESB reservations attach to. AFVC carries the operations that consume the components RESB reserves. PLAF carries planned order data for requirements that have not yet been converted to a production order. MDTB and MDKP represent the MRP list view where the same requirement appears as an MRP element. Transactions that write or change RESB rows include order creation and release, goods issue posting against an order, and manual reservation maintenance.