LIPS table — Delivery Item Table LIPS

Each row in LIPS is one item on one delivery document, whether the delivery is outbound (goods issue to a customer), inbound (goods receipt from a vendor or plant), or a stock transfer delivery. The row carries the material number, the quantity actually placed on the delivery in both the delivery unit and base unit, the plant and storage location the stock is coming from or going to, batch and serial data where relevant, and the picking and PGI status of that specific item. It also carries pointers back to the sales order or purchase order item that generated the delivery and, once goods movement happens, the pointer to the material document. A single sales order item can spawn multiple LIPS rows across multiple deliveries if the order is split, backordered, or partially delivered.

LIPS-VBELN joins to LIKP-VBELN for the delivery header, giving ship-to, shipping point, and overall PGI date. LIPS-VGBEL and LIPS-VGPOS join to VBAP-VBELN and VBAP-POSNR to reach the sales order item that triggered the delivery, though this direct join only works reliably for the first level; for multi-step document flow, VBFA is the safer path. VBFA-VBELV/POSNV holding the sales order and VBFA-VBELN/POSNN holding the delivery, filtered on VBTYP_N for delivery, is how consultants trace order-to-delivery-to-billing chains without assuming a flat VGBEL link. LIPS-MATNR joins to material master tables for description and unit conversion. LIPS-WERKS and LGORT join to plant and storage location master data for stock determination checks.

Always restrict on MANDT plus VBELN when a specific delivery is known; VBELN is the natural key alongside POSNR and both are indexed. LIPS is large in any live O2C system because every partial delivery, every backorder split, and every return generates new rows, so an unrestricted material or date-range scan is expensive and often blocked by basis. If searching by material or plant across a date range, go through LIKP first to narrow the delivery number set, since LIPS itself has no reliable header date field for filtering. Do not attempt to sum LFIMG across a customer or material without also grouping by unit of measure, because mixed units silently produce a meaningless total.

To confirm a sales order item was under-delivered, select LIPS with VGBEL equal to the sales order number and VGPOS equal to the order item, sum LFIMG in the base unit across all resulting rows, and compare that sum against VBAP-KWMENG for the same item. If the summed LFIMG is less than KWMENG and no further open delivery exists in VBEP, the shortfall is a real delivery gap, not a display artefact.

LIPS remains a transparent table in S/4HANA and continues to be written by standard delivery processing; it has not been replaced. S/4HANA exposes delivery item data through CDS views built on top of LIPS for Fiori apps and embedded analytics, but the underlying table and its key structure are unchanged from ECC. Custom reports and interfaces built directly against LIPS continue to work without remediation on migration.