VEKP table — Handling Unit Header Table

One row in VEKP represents a single handling unit - a physical packed object such as a pallet, crate, drum, or shipping carton created during outbound packing, inbound packing, or repacking. The row exists independently of any sales or delivery document; it describes the unit itself, not its contents or its assignment. Weight and volume on the row are aggregates rolled up from everything packed inside, recalculated as items are packed and unpacked. Status fields track whether the HU is still open for packing, has been packed complete, or has been shipped/goods-issued. Because a handling unit can be nested inside another handling unit (a box inside a pallet), a VEKP row can itself be a packed item referenced from another HU, which is where a lot of confusion in reporting comes from.

VEKP is client-dependent; always restrict on MANDT plus a real selection field, never pull it unfiltered. The table grows with every packing operation across every warehouse and every delivery, so it is not small in a mature system. VENUM is the most selective field when known; EXIDV (the barcode) is the second most useful because that is what operators actually scan and quote when reporting a problem. Do not try to filter by delivery number directly on VEKP - it is not there. If starting from a delivery, go through VEPO first to get the VENUM values, then read VEKP for the header attributes. Filtering on STATUS alone across the whole table is expensive and rarely selective enough to be useful without another restriction.

Symptom: a pallet label shows the wrong gross weight. Take the SSCC printed on the label and select VEKP where EXIDV equals that number to get VENUM, BRGEW, NTGEW, TARA and GEWEI. Then select VEPO where VENUM equals that value to see every line packed into it, and sum the net weights against LIPS quantities to check whether the aggregate on VEKP actually matches what is packed. A mismatch between the VEKP aggregate and the VEPO sum points to a packing update that did not trigger a weight recalculation, not to a master data error on the material.

VEKP is unchanged in shape and continues to be the handling unit header table in S/4HANA for the classic Handling Unit Management scenario used with standard SD deliveries. Where extended warehouse processing is run through decentralized EWM, handling unit data is primarily managed and reported in the EWM system's own tables, with VEKP in the ERP/S4 system reflecting only what has been passed back through the integration. No CDS compatibility view replacement is required for VEKP itself since it remains the live table for this scenario.

Packing content and weight discrepancies are a warehouse/logistics execution question first - whoever owns the packing station process (WM or basic packing in SD) checks VEPO against VEKP before anyone touches configuration. Master data for packaging materials (VHILM) sits with material master ownership. Only escalate to a developer once the VEKP aggregate is confirmed to genuinely disagree with the VEPO detail after a fresh packing action, not before.

VEPO is the item table packed under each VEKP row and is written by the same packing transactions (delivery packing, inbound packing, repacking) that write VEKP. LIPS and LIKP are the delivery item and header tables that VEPO references to say what is being packed and against which delivery. Packing is normally triggered from delivery processing transactions; direct table maintenance of VEKP/VEPO outside those transactions will desynchronize the aggregates from the actual packed content.