VBEP table — Sales Document Schedule Line Data

Each row in VBEP is one schedule line belonging to one sales document item. A sales order item (VBAP) can be split into multiple schedule lines when the requested quantity cannot be confirmed in a single date, when the customer asks for staggered delivery, or when availability check (ATP) confirms partial quantities on different dates. VBEP holds the requested quantity, the confirmed quantity, the material availability date, the loading date, the transportation planning date, and the delivery date for that specific slice of quantity. Standard items usually carry one schedule line, but rush orders, backorder-processed items, and make-to-order items frequently carry several. The table is the actual source of what will eventually go into a delivery, not the item table itself, which is a common source of confusion.

Always restrict on MANDT first, then VBELN, then POSNR before touching ETENR; VBELN plus POSNR alone still returns multiple rows if the item has split schedule lines. The table is large in any live system with backorder processing running regularly, so a selection on EDATU or LIFSP alone across the whole client is expensive and usually unnecessary. When checking a specific order, go in through VBAK/VBAP first to get VBELN and POSNR, then read VBEP for those keys. When checking blocked schedule lines system-wide, restrict by LIFSP not equal to blank together with a date range on EDATU, never by LIFSP alone.

Symptom: sales order item shows full quantity but delivery only picked up part of it. Select VBEP for that VBELN and POSNR. If more than one row comes back, the item was split into multiple schedule lines; compare WMENG against BMENG on each row. A confirmed quantity (BMENG) lower than the requested quantity (WMENG) on any line explains the shortfall directly, independent of anything visible on the VBAP item itself, which shows only the summed requested quantity.

VBEP is unchanged in structure between ECC and S/4HANA and continues to be maintained by the same sales order logic. It is not one of the tables replaced by a CDS-based simplified data model; sales document header, item and schedule line data remain in VBAK, VBAP and VBEP in both releases. Some newer Fiori apps and CDS views for order fulfillment read from VBEP underneath, but the table itself is not deprecated.

Confirmed quantity and delivery date discrepancies on schedule lines are an SD order management question, usually resolved by whoever configures availability check and requirements class, not by a basis or ABAP team. If the numbers in VBEP look wrong relative to what ATP should have confirmed, the checkpoint is the ATP customizing and the material's requirements strategy, not the table.

VBAK and VBAP hold the header and item this table hangs off. VBUP carries the status flags (delivery status, goods issue status) at the same schedule line granularity. VBFA records the document flow once a schedule line's quantity is copied into a delivery. VBEH holds scheduling agreement schedule line history, a related but distinct concept for agreements rather than one-time orders. Sales orders are created and changed through the standard order transactions, which write VBEP automatically on save; direct changes to the table outside that path are not supported.