EKET table — Purchase Order Schedule Lines Table EKET

One row in EKET is one delivery schedule line for one purchase order or scheduling agreement item. A standard PO item with a single delivery date still gets exactly one EKET row, generated automatically when the item is created; a PO item split across several delivery dates, or a scheduling agreement item with multiple releases, gets one row per date. Each row carries the planned or confirmed delivery date for that slice of the item, the quantity scheduled for that date, and running totals of what has actually been received or issued against that specific line as goods movements post. EKET is where SAP tracks partial delivery progress at the sub-item level; EKPO only ever shows the item's overall target quantity and its own rolled-up received quantity, not the breakdown by date.

Always restrict on MANDT, then on EBELN, and add EBELP as soon as it is known; a scan of EKET without an EBELN range on a mature system is a table scan across every schedule line ever created, including closed and historical ones. EINDT alone is not selective in a large date range because it repeats across many unrelated orders; pair it with a vendor or plant filter carried over from EKKO or EKPO if searching by date. There is no delete flag on EKET rows themselves that mirrors EKPO's deletion indicator, so a schedule line for a deleted or cancelled item can still be present and must be cross-checked against the item's own status before drawing conclusions from quantities alone.

To confirm a 'partial delivery not showing as complete' complaint, select EKET on EBELN and EBELP for the item in question and compare each row's MENGE against WEMNG. A line where WEMNG equals MENGE is fully received; a line where WEMNG is less than MENGE but greater than zero is a genuine partial receipt on that specific schedule date, not a data error. If the item has several EKET rows, sum WEMNG across all of them and compare that total to EKPO's own received quantity to check they reconcile.

EKET remains the underlying transparent table on S/4HANA and continues to be populated exactly as on ECC; there has been no structural redesign of the schedule line concept. Reporting on purchasing documents in S/4HANA is increasingly done through the purchase order compatibility CDS views rather than direct table access, but those views expose the same schedule line data sourced from EKET underneath. Custom code that reads EKET directly still works unchanged.

Questions about why a delivery is split, why a date moved, or why a receipt did not close out a schedule line belong to the buyer or the MM/procurement functional consultant who configured the delivery schedule and confirmation control on the vendor or purchasing info record. Questions about whether a specific goods movement posted correctly are inventory management territory; EKET only reflects the outcome, it does not decide it.

EKPO is the parent item table and the natural first stop before EKET. EKKO holds the document header. EKBE carries the history of individual goods receipt and invoice postings that update EKET's cumulative fields, transaction ME23N displays both the item and its schedule lines together, and ME38 or ME84 are used for scheduling agreement delivery schedules that generate and change EKET rows directly.