LTAP table — Transfer order item table in classic WM

One row in LTAP represents a single transfer order item: one instructed movement of a quantity of a material (or handling unit) from a source storage bin to a destination storage bin within a warehouse number, under one transfer order header. A transfer order can and usually does have several items, for example one item per batch, one item per source bin when stock is split across bins, or separate items for pick and putaway steps in two-step confirmation. The row records what was planned to move, what quantity was actually confirmed, which storage type and bin were involved on both ends, and whether the item is still open or has been confirmed. LTAP does not itself trigger the movement in inventory management; the underlying goods movement is posted separately and referenced back to the transfer order item.

LTAP is client-dependent and typically restricted first by LGNUM, then by TANUM if a specific transfer order is under investigation, or by a date range plus movement type when scanning for a pattern. It is not small in a busy warehouse; never select without at least warehouse number and a date or transfer order range. PQUIT and the quit-status fields on LTAK are the fast filters for open versus confirmed work — do not scan the whole table by material or bin range alone, since bin and material fields are not primary keys and a full scan on those criteria is expensive. When chasing a specific item, TANUM plus TAPOS is unique and cheap.

Symptom: a putaway task appears to be missing from the warehouse monitor for a given transfer order. Select LTAP by LGNUM and TANUM and check whether the item row exists at all; if it does not exist, the transfer order was never created with that item, which points upstream to the transfer requirement or delivery. If the row exists, check PQUIT: if unconfirmed, the task is genuinely still open and the monitor is correct; if confirmed, compare VSOLM against NISTA to see whether a partial confirmation, not a missing task, is the real issue.

LTAP is a classic Warehouse Management table and remains in use on S/4HANA for warehouses still running classic WM or Lean WM in the logistics execution layer. It is not the table behind Extended Warehouse Management; EWM-managed warehouses use a separate set of order and item tables built on the EWM data model, and LTAP simply does not get populated for those warehouse numbers. On a system running both, the presence or absence of LTAP rows for a warehouse number is itself a quick way to tell whether that warehouse is classic WM or EWM.

Questions about a specific LTAP row belong to the warehouse operations or WM configuration consultant who owns transfer order processing for that warehouse number. Systemic questions about missing or duplicated items, or performance on the table, belong to whoever owns the WM/EWM technical configuration, in coordination with the basis or archiving team if volume or history retention is the concern.

LTAK is the transfer order header LTAP always belongs to; both are written together by the transfer order creation and confirmation transactions. LAGP supplies the bin master data referenced by the source and destination bin fields, and LQUA holds the quant that the item consumes or creates. LTBK and LTBP represent the transfer requirement that frequently generates the transfer order in the first place, useful when a transfer order item cannot be explained from delivery data alone.