LIKP table — LIKP - Delivery Header

One row in LIKP represents one delivery document header, whether outbound or inbound, created from a sales order, a stock transport order, or manually. It carries the delivery type, the shipping point that owns the document, the ship-to party, the planned delivery date, and the dates that track physical progress: picking start, loading, and goods issue, both planned and actual. It also carries the route and, once relevant movements have posted, the actual goods issue date that marks the delivery as goods-issued. It does not carry line item quantities, materials, or batch data - those sit in LIPS. A delivery with zero items is still a valid LIKP row, which is one of the more common sources of confusion when reconciling delivery counts against order lines.

LIKP grows with every delivery ever created, so a plant or shipping point without a date range restriction will return years of history. Always restrict on MANDT first, then narrow by VSTEL, LFART and a date range on ERDAT or LFDAT before adding anything else - these are the fields with real selectivity. VBELN alone is fine for point lookups but useless for range analysis since delivery numbers are assigned sequentially with no business meaning. WADAT_IST blank versus populated is the fastest way to separate open deliveries from goods-issued ones without touching status tables, but confirm it against VBUK for anything that has to be reported as a status rather than inferred.

Symptom: a customer complains goods never left the warehouse despite the delivery being confirmed as shipped. Select LIKP where VBELN equals the delivery number and check WADAT_IST. If it is blank, no goods issue has posted regardless of what any downstream system or printed document claims. Cross-check LIPS for that VBELN to confirm the items still show open quantity, and check VBFA to see whether a goods movement document was ever created against the delivery at all.

LIKP is unchanged as a physical table in S/4HANA and continues to be populated by the same delivery creation and goods movement logic. It is exposed through delivery-related CDS views for reporting and Fiori apps, but consultants troubleshooting at the ABAP or table level still read LIKP and LIPS directly the same way they did in ECC. No field renaming or structural split has happened to this table.

Logistics execution or SD functional consultants own configuration questions on delivery types, shipping points and copy control into billing. Warehouse or transportation teams own why a specific delivery has not moved past picking. A data question that spans LIKP, LIPS and inventory movement tables together usually needs someone who can also read MM-IM postings, not SD alone.

LIPS holds the item detail for every LIKP row and is written by the same delivery transactions. VBFA is the document flow table that links deliveries back to sales orders and forward to billing documents. VTTP and the shipment tables pick up the delivery for transportation planning. VBUK and VBUP carry the overall and item status flags that LIKP itself does not store. Deliveries are created and changed through the standard outbound delivery transactions and through background delivery due list processing.