ESLL table — Service Line Items Table

One row in ESLL represents a single service line: a specific service (from the service master, or entered as free text) with its quantity, unit of measure, and monetary value, belonging to a service package identified by a package number. Service procurement in MM does not put services directly on the purchase order item; instead the PO item (with item category D) points to a package number, and that package number is exploded into one or more ESLL rows, which can themselves be structured hierarchically through sub-package numbers. The same package structure is reused when a service entry sheet is created to confirm work performed, so ESLL rows also get referenced from the confirmation side, not only from the ordering side. A package with no ESLL rows is an empty service specification.

Always restrict on MANDT and never scan ESLL by SRVPOS or KTEXT1 alone across a productive client; the table is unindexed for those fields and a wide scan on a mature system with heavy service procurement will run long. The only reliably selective entry point is PACKNO, so the practical sequence is: get the package number off EKPO for the PO item, or off ESSR for the entry sheet, then select ESLL on that PACKNO. If the hierarchy matters, also read SUBPACKNO to decide whether a row is a leaf service line or a grouping node, because summing NETWR across all rows of a package double-counts value if sub-package header rows are included alongside their own children.

Symptom: a service PO item shows a total value that does not match what the buyer expects on the printed service specification. Pull the package number from EKPO-PACKNO for that item, then select ESLL where PACKNO equals that value, sorted by EXTROW. Sum NETWR only for rows where SUBPACKNO is initial (leaf lines), and compare that total to the PO item's net value; a mismatch usually means either a price change was made directly on a service line after entry sheet acceptance, or a sub-package total was counted twice.

ESLL continues to exist as a transparent table in S/4HANA and service procurement still uses the package-and-service-line model built on ESLL, ESLH and the related service tables. There is no indication that this structure was retired or replaced by a compatibility view in the way some classic MM tables were; the service procurement data model has been architecturally stable across ECC and S/4HANA. Any version-specific extension of the service master model should be confirmed against the current release rather than assumed.

Functional ownership sits with MM procurement, specifically whoever configures service procurement and maintains service master data; buyers and service coordinators own the content of individual service lines. Data questions that cross into cost object assignment or invoice matching pull in the accounting or controlling counterpart, since the account assignment and settlement of service lines is a shared decision, not a pure MM one.

EKPO holds the purchase order item (category D) whose PACKNO points into ESLL. ESSR is the service entry sheet header that confirms the same package. EKKN carries account assignment, and the equivalent account assignment table for service lines is keyed the same way as ESLL but is a distinct object. Transactions that write or display this chain include the service PO maintenance transaction, the service entry sheet transaction, and the service master maintenance transactions.