VTTK table — Shipment Header Table
VTTK stores one row per shipment document created in transportation processing (transaction VT01N/VT02N). It holds the shipment number, shipment type, transportation planning point, mode of transport, route, carrier-related identification, and the planned start and end dates and times. It does not store the deliveries carried in the shipment or the actual goods movement, both of which live elsewhere.
This page covers the VTTK shipment header table used in SAP Logistics Execution transportation processing. It focuses on which fields are trustworthy, how the header joins down to shipment items and deliveries, and the recurring mistakes consultants make when reading shipment status and dates off this table alone.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,119 words
What it stores
One row in VTTK represents a single shipment document: the transportation instruction that groups one or more deliveries (or, in some setups, purchase order based inbound movements) onto a means of transport for planning and execution. The header carries the classification of the shipment (shipment type, mode of transport, route), the organizational unit responsible for planning it (transportation planning point), identification data, and planned timing. It does not carry weight, volume, or the list of deliveries assigned to it — those live one level down, in the shipment item table, and further down in the shipment stage table for leg-level planning. VTTK is created and changed through the shipment maintenance transactions and is read constantly by shipment cost calculation, output determination, and freight settlement processes downstream of delivery creation.
Key fields
- MANDT - client, always the first restriction
- TKNUM - shipment number, the primary key and the value used everywhere else to join into shipment tables
- SHTYP - shipment type, the configuration key that drives numbering, item categories allowed, and output
- TPLST - transportation planning point, the organizational unit that owns the shipment
- VSART - mode of transport (road, rail, sea, air) as set on the shipment
- ROUTE - route assigned to the shipment; can be repopulated or overridden during planning and does not have to match the route on the originating sales order
- ERDAT, ERNAM, ERZET - creation date, user, and time, useful for tracing when the shipment was built relative to the delivery
- ADD01 to ADD04 - planned start date, planned start time, planned end date, planned end time on the shipment header
How it joins the data model
- VTTK-TKNUM = VTTP-TKNUM, header to shipment item, since one shipment can carry many deliveries or items
- VTTP-VBELN = LIKP-VBELN, shipment item to delivery header, the join that tells which delivery physically travels in this shipment
- LIPS-VBELN = LIKP-VBELN, delivery item to delivery header, needed to get material, quantity, and weight for what the shipment is actually moving
- VBFA-VBELN = VTTK-TKNUM, document flow entry recording the shipment as a subsequent document of the delivery, filtered on the document category for shipments
How to read it safely
MANDT first, always. TKNUM is the natural key and highly selective, so if a shipment number is in hand, everything else is fast. The table is not enormous compared to VBAK or LIKP, but it is still not safe to scan without restriction in a productive system with years of transportation history. Restrict by TPLST and a date range on ERDAT or the planned start date before adding SHTYP or VSART as secondary filters. Never select on ROUTE alone expecting it to match the sales order route; it is shipment-level data and gets reassigned during planning. Do not treat the ADD01-ADD04 fields as actuals — they are the planned schedule, not what happened.
How to prove it in the data
Symptom: a delivery shows as shipped in the sales order status but the customer says nothing arrived. Pull the delivery number, join LIKP-VBELN to VTTP-VBELN to find the shipment number, then read VTTK by that TKNUM. Check SHTYP to confirm the shipment was actually completed for that type, and compare ADD01/ADD03 (planned dates) against whatever actual departure or completion status is recorded on the shipment item or stage level. If VTTP shows no row for that delivery, the delivery was never assigned to a shipment despite the sales order status.
ECC vs S/4HANA
VTTK remains a transparent table in S/4HANA and continues to be populated by the same shipment maintenance transactions where classic Logistics Execution transportation is used. There is no widely used compatibility view replacing it, because transportation planning of this kind either stays in core ERP LE-TRA or is handled through a separate SAP Transportation Management system integrated via interfaces, in which case VTTK may simply be unused or lightly used depending on how the interface is configured. Do not assume its presence or absence indicates which transportation solution is active without checking the integration setup.
Common pitfalls
- Assuming one delivery equals one shipment. Deliveries are frequently consolidated into a single shipment or split across several; the relationship only exists through VTTP, never assume a 1:1 join between LIKP and VTTK
- Reading ADD01-ADD04 as actual departure and arrival times. They are the planned schedule set during shipment creation or planning; actual execution is tracked at item or stage level and can diverge significantly from the plan without VTTK ever being updated
- Trusting ROUTE on the shipment as proof of the route quoted to the customer on the sales order. Transportation planning can reassign a different route for cost or capacity reasons, and the two fields are independently maintained
- Assuming shipment number sequence reflects delivery creation order. TKNUM is assigned from its own number range at shipment creation time, which can happen well after the delivery, or in batches that mix deliveries created on different days
- Concluding a shipment with no linked billing means nothing has been invoiced. Shipment cost documents and customer billing are separate document flows; a shipment can be fully costed for freight settlement while the underlying sales order billing is untouched, or vice versa
- Filtering on SHTYP without checking configuration for that shipment type. The same field value can carry very different business meaning across planning points if shipment types were copied and renumbered inconsistently during rollout
Whose problem this is
The logistics execution or transportation functional consultant owns questions about shipment header data and shipment type configuration. The SD consultant owns the delivery side of the join and any discrepancy between sales order commitments and what was actually shipped. Master data for planning points and routes is typically configuration-owned by whichever team runs the transportation planning point setup, not by SD alone.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/vttkERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.