LT10 — List of Transfer Requirements in Classic WM

LT10 opens a selection screen and produces a list of Transfer Requirements (TRs) that exist for a warehouse number, restricted by criteria such as TR number, movement type, plant, storage location, or requirement type. The structural fact that causes most confusion: LT10 does not create anything. A TR is a demand document generated upstream by a delivery, a production order, or a manual posting; LT10 only surfaces TRs that already exist in the system and shows whether a Transfer Order has been created against them yet. The actual TO creation, when triggered from this list, calls the same underlying logic as LT01/LT04/LT06/LT09 - LT10 is the worklist, not the engine.

LT10 is used when TRs are piling up without corresponding TOs - typically flagged by a warehouse supervisor checking backlog before a shift, or by a consultant investigating why stock movements requested by production or sales are not physically happening in the warehouse. It sits between demand creation (delivery save, production order release, inventory posting) and physical execution (TO confirmation). Consultants reach for LT10 instead of LT22 (TO list) specifically when the question is 'why hasn't this requirement turned into a task yet', not 'where is this task now'. There is no Fiori equivalent in classic WM; the transaction is used as-is on both ECC and decentralized WM on S/4HANA.

In SE16 or SE16N, open the Transfer Requirement header table for the warehouse number and TR number in question and check the status indicator that records whether a TO has already been created for it. Cross-reference by TR number against the Transfer Order header table to see if a TO number is populated; if it is not, the TR is genuinely open and the gap is upstream (delivery, production order, or manual TR not yet worked) rather than in LT10 itself. If a TO number is populated but LT10 still lists the TR as open, the selection filter on the report, not the data, is the problem.

Where S/4HANA still runs classic or decentralized Warehouse Management, LT10 behaves the same as on ECC with no functional change. In an embedded EWM implementation, the Transfer Requirement concept as used by classic WM does not carry over in the same form - EWM works with warehouse requests and warehouse tasks generated directly from the outbound/inbound delivery, and LT10 is not part of that stack. There is no direct Fiori replacement for LT10; the nearest EWM equivalent is the warehouse task and warehouse request monitoring apps, which are structurally different objects, not a one-to-one substitute.

Functional WM/logistics execution consultant territory in nearly all cases. ABAP involvement is only needed if a custom variant or report wraps LT10's selection logic. Basis is not involved unless the TO creation batch job scheduled from this list is failing to run. A good handover includes the warehouse number, the exact selection criteria used, the TR number affected, and whether the TR's source document (delivery, order) was confirmed to exist and be WM-relevant.

Read LT01 to understand how a TO is actually created against a TR, since LT10 only exposes the same creation logic through a list. LT21 and LT22 cover TO display and listing once the TR has been converted, useful for following a requirement through to physical execution. LT23 helps when tracing a specific material across multiple TOs. LB10, LB11 and LB12 are worth comparing since they cover TO/TR lists filtered by material or storage type rather than by TR number range, and are sometimes reached for by mistake when LT10 was the correct choice.