LT02 — Change Transfer Order in Classic WM
LT02 changes an existing transfer order (TO) in classic Warehouse Management before it has been confirmed. It lets a consultant correct source or destination storage bin, quantity, or storage unit on a TO item. Once an item is confirmed, even partially, that portion is locked and only the open remainder can still be edited or cancelled.
This page covers LT02, the classic WM transaction for changing a transfer order that has already been created. It focuses on why changes are refused after partial confirmation, how quant and delivery status interact with the change, and the diagnostic sequence for the most common save errors.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,127 words
Purpose
LT02 opens an already-created transfer order (TO) so its item lines can be corrected before the move is executed on the shop floor. Typical edits are source storage type or bin, destination bin, quantity, or storage unit number. The structural fact that explains most confusion: a TO item is split internally between confirmed and open quantity. LT02 can only touch the open portion. If a picker has already confirmed part of the item in LT12 or via mobile data entry, that confirmed slice is frozen and LT02 will either refuse the change outright or silently apply it only to the remaining open quantity, which looks like a partial fix to anyone who did not check confirmation status first.
When it is used
Reached for mid-process, after a TO exists (created via LT01, LT06 from a delivery, or LT10 for multiple items) but before or during picking. Common triggers: the picker reports the source bin is empty or damaged, the system-proposed bin is physically inaccessible, a quantity was overstated at creation, or a batch needs correcting before movement. It is not used for a TO that is already fully confirmed - that requires cancellation and a new TO, not a change. There is no Fiori app equivalent because this is classic decentralized-independent WM; embedded or decentralized EWM handles the equivalent correction through warehouse task adjustment, not LT02.
How to use it in practice
- Call LT02 and enter the warehouse number and TO number directly, or use the matchcode to find the TO by delivery, material, or storage unit
- Press enter to load the TO header and the item overview screen
- Select the item line that needs correction; confirmed items will show as protected or greyed depending on configuration
- Change the source or destination storage type and bin, the quantity, or the storage unit as needed on the open portion of the item
- Cancel an item line entirely if the movement is no longer required, rather than trying to zero out the quantity
- Save; the system re-checks bin capacity, mixed-storage rules, and quant availability before accepting the change
Key data objects
- LTAK - transfer order header: warehouse number, TO number, source document reference, overall status
- LTAP - transfer order item: storage type, source and destination bin, planned quantity and confirmed quantity, batch, storage unit number
- LQUA - warehouse management quant: quantity blocked or reserved for the TO, updated when the item's bin or quantity changes
- LIPS - delivery item, when the TO originates from an inbound or outbound delivery; delivery quantity and status can constrain what LT02 is allowed to change
How to prove it in the data
In SE16 on LTAP, filter by warehouse number and TO number to pull the item lines, and compare the planned transfer quantity field against the confirmed quantity field for that item - a nonzero confirmed value on the line explains why LT02 rejected or partially applied the intended change. Cross-check LQUA for the same storage bin and material to see whether the quant still shows the old reserved quantity, which points to a change that was saved on the TO but not yet reflected in stock. If the TO is delivery-driven, check LIPS status fields for the same document number to rule out a delivery-side block.
ECC vs S/4HANA
LT02 exists and behaves the same way on S/4HANA when classic embedded WM is in use; nothing about the transaction itself changed. There is no Fiori app replacement for it. Where decentralized or embedded EWM is used instead of classic WM, the underlying object is a warehouse task rather than a transfer order, and the equivalent correction happens through EWM's task change functionality, which follows different confirmation-lock rules entirely.
Common pitfalls and how to diagnose them
- Confirmed item locked: the most frequent complaint is that a field will not accept a new value. Check the confirmed quantity on the LTAP item first, before assuming a bug. If confirmed quantity is nonzero, the fix is to change only the open remainder or to cancel the confirmed portion through the proper confirmation-reversal path, not to force the field.
- Bin capacity or mixed-storage rejection at save: changing the destination bin can trigger a hard stop if the new bin's capacity check or mixed-storage indicator conflicts with existing stock. Read the exact error text; it usually names the storage type check, not the bin itself, which misleads consultants into blaming the wrong bin.
- Delivery status lock: for TOs generated from an inbound or outbound delivery, some fields (quantity, route-relevant data) are only changeable from the delivery side. LT02 will either grey the field or accept the change without syncing it back to the delivery, producing a quantity mismatch that only surfaces later at goods issue or goods receipt.
- Batch or storage unit split: changing the bin on a batch-managed item can force the system to split the line into two TO items rather than update the existing one. If a report later shows two lines where one was expected, this is the cause, not a duplicate posting.
- Authorization by storage type: the user can open LT02 and see the item but the save fails or the field is not editable because the authorization group tied to the source or destination storage type excludes that user. This looks identical to a status lock until the authorization trace is checked.
Whose problem this is
Functional WM/logistics execution issue in nearly all cases. Basis involvement is limited to storage-type authorization group problems. ABAP is only relevant if a custom user exit or BAdI blocks the change with a non-standard message. A good handover includes the warehouse number, TO number and item, the exact error message text, and whether the item shows any confirmed quantity.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/lt02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.