LTAK table — LTAK Transfer Order Header Table
LTAK is the classic SAP Warehouse Management (LE-WM) header table for transfer orders. Each row represents one transfer order document instructing a physical stock movement between storage bins, storage units, or interim areas inside a warehouse number, carrying the movement type, creation data, and confirmation status. Line-level bin and quantity detail lives in the companion item table LTAP.
This page covers LTAK, the transfer order header table in classic SAP Warehouse Management, and how to read it during picking, putaway, and confirmation troubleshooting. It focuses on how a transfer order relates to its items, the storage bin and unit tables, and the mistakes consultants make when they treat header status as proof of physical stock movement.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,070 words
What it stores
One row in LTAK represents one transfer order (TO) in classic LE-WM: the instruction telling a warehouse worker or automated system to move a defined quantity of stock from a source storage bin or unit to a destination storage bin or unit within one warehouse number. The TO is the execution-level document sitting below the transfer requirement or the outbound/inbound delivery; it is what actually drives physical movement and RF confirmation. The header carries the movement type that governs posting logic, the warehouse number the TO belongs to, who created it and when, and whether the TO has been fully confirmed. It does not carry bin, quantity, or material detail directly - that lives one level down in the item table, keyed to the same transfer order number.
Key fields
- MANDT - client
- TANUM - transfer order number, the primary business key together with LGNUM
- LGNUM - warehouse number (warehouse complex) the transfer order belongs to
- BWLVS - movement type controlling how the transfer order posts and which screens/checks apply
- BDATU - date the transfer order document was created
- ERNAM - user who created the transfer order
How it joins the data model
- LTAK-TANUM = LTAP-TANUM and LTAK-LGNUM = LTAP-LGNUM, header to item, one TO can have many item lines
- LTAP-LGNUM/LGTYP/LGPLA = LAGP-LGNUM/LGTYP/LGPLA, item source or destination bin resolved against the bin master
- LTAP-LGNUM/LENUM = LEIN-LGNUM/LENUM, item source or destination storage unit where handling unit management is active
- LTBK-TANUM = LTAK-TANUM, links the transfer requirement header that generated the TO where a requirement-based flow was used
- LTAP-MATNR/WERKS/LGNUM = MLGN-MATNR/WERKS/LGNUM, item material resolved against warehouse-specific material master data
How to read it safely
LTAK is keyed by client, warehouse number, and transfer order number, and TANUM is assigned from a number range per warehouse number, so it sorts and filters cleanly by LGNUM plus a TANUM or date range. The header table itself stays relatively small and cheap to query; the cost appears when a consultant joins straight into LTAP without first narrowing LTAK, because item lines multiply per TO and per split. Always restrict by LGNUM first, then by BDATU range or TANUM range, before pulling item detail. Never select across all warehouse numbers in a client with only a material number as filter - that scan is unbounded and slow in any sizeable warehouse.
How to prove it in the data
Symptom: a goods issue was posted against a delivery but the storage bin still shows the stock as available. Select LTAK for the relevant LGNUM and a BDATU range around the posting date, then join to LTAP for the material and destination bin in question. If the confirmation status on the TO is still open, the two-step picking process has generated the transfer order but the physical move and confirmation have not happened yet - the goods issue on the delivery side does not, by itself, mean the bin quantity moved.
ECC vs S/4HANA
LTAK is a classic LE-WM table and remains present and populated on S/4HANA for any warehouse number still run under classic Warehouse Management rather than embedded EWM. It has not been redesigned or moved behind a compatibility view in that scenario; the structure and posting logic carry over largely unchanged. Where a warehouse has been migrated to embedded EWM, transfer orders are represented in the EWM warehouse task and warehouse order data model instead, and LTAK simply is not used for that warehouse number at all - the two models do not share tables.
Common pitfalls
- Treating the existence of a transfer order as proof that stock has physically moved. A TO can be created and never confirmed; the bin quantity only changes on confirmation, not on creation.
- Assuming BWLVS in LTAK is the same value as the movement type seen in the material document. WM movement type and MM movement type are related but separate configuration objects, and a mismatch investigation that starts from the wrong one wastes time.
- Reading BDATU as the time the physical movement occurred. It reflects when the TO document was created, not when a picker actually executed the move.
- Cancelling or reversing a single transfer order and assuming the whole outbound delivery or transfer requirement is reversed with it. One delivery can be split across several transfer orders, and reversing one leaves the others standing.
- Deleting a transfer order in the UI and expecting the header row to disappear from LTAK. Cancelled TOs are usually flagged, not removed, and old rows persist unless archiving has run.
- Selecting LTAP or LQUA for a bin discrepancy without first checking LTAK for an open, unconfirmed TO against that same bin. An open TO explains an apparent discrepancy that is really just work in progress.
- Ignoring table growth. LTAK and LTAP grow with every pick and putaway and are rarely archived aggressively in early project phases; unbounded selections that worked fine at go-live start timing out a year later and get misdiagnosed as a functional bug.
Whose problem this is
A question about a specific transfer order's status or confirmation belongs to the WM or EWM functional consultant supporting that warehouse, working with the warehouse operations key user who can confirm what actually happened on the floor. Volume, archiving, and performance questions on LTAK/LTAP sit with basis or the data management workstream once the functional read on the document is settled.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/ltakERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.