LB11 — List and Process Transfer Requirements by Material
LB11 is a classic WM list transaction that displays open transfer requirements selected primarily by material and plant, and lets the user create transfer orders directly from the selected lines. It does not create transfer requirements itself; it is a worklist for converting requirements that already exist into transfer orders, distinguishing it from LB10 which selects by movement type.
This page covers LB11, the material-keyed transfer requirement list in classic Warehouse Management, and how it is used to convert open TRs into transfer orders. It focuses on the diagnostic patterns behind empty lists, partial conversions, storage bin determination failures, and lock contention, since the underlying object model is small.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,217 words
Purpose
LB11 opens a selection screen for warehouse number, material, plant, storage type and movement type, then returns a list of open transfer requirement items matching those criteria. From that list the consultant selects one or more lines and triggers transfer order creation, either in a single step or as a two-step process depending on how the storage type and movement type are configured. The structural fact that causes most confusion is that LB11 never creates or changes a transfer requirement itself: that belongs to LB01 and LB02. LB11 is purely a monitor-and-convert screen, keyed by material rather than by movement type as LB10 is. If a requirement does not appear on the list, the requirement either does not exist, has already been fully converted, or falls outside the selection filter, not because LB11 is broken.
When it is used
LB11 is reached for when someone needs to work through open transfer requirements for a specific material or small set of materials, typically during putaway or internal stock movement processing where the driving question is 'what still needs to move for this material' rather than 'what needs to move for this movement type'. It sits between requirement creation (LB01, or automatic creation from goods movements) and transfer order execution (LT03, LT12). It is not used for outbound delivery-driven picking, which goes through LT10 and LT12 against delivery documents instead of transfer requirements. In an EWM or embedded EWM landscape this transaction is not reached for at all, since the TR/TO model is replaced by warehouse tasks and warehouse orders.
How to use it in practice
- Enter the warehouse number and narrow the selection by material, plant and storage type; leave movement type open unless the volume is large
- Execute and review the resulting list of open transfer requirement items, checking the open quantity column against expectations
- Select the relevant line or lines, using multiple selection if several items need the same conversion treatment
- Trigger transfer order creation from the list, choosing single-step or two-step depending on the process
- Review or override the storage type and bin search proposal on the TO creation screen if prompted
- Save; confirm the resulting transfer order number and check the TR item's open quantity has dropped accordingly
Key data objects
- LTBK - transfer requirement header, holds warehouse number, requirement number, requirement type and overall status
- LTBP - transfer requirement item, holds material, plant, storage type, requested quantity and open quantity; this is the table LB11 actually reads and where partial conversion is visible
- LTAK - transfer order header created when LB11 triggers TO creation, holds the new TO number and reference back to the requirement
- LTAP - transfer order item, holds source and destination storage bin, quantity confirmed, and the link to the originating LTBP item
- LQUA - quant table checked implicitly during bin search when the system proposes a source storage bin for the TO
How to prove it in the data
Pull LTBP filtered by warehouse number and material, and inspect the open quantity field against the originally requested quantity to see whether the requirement is fully open, partially converted, or already closed. Join back to LTBK on the requirement number to read the overall requirement status. To confirm a suspected duplicate or missing conversion, query LTAP filtered on the same material and warehouse number and check whether a transfer order item already references the requirement number found in LTBP; if one does and the LTBP open quantity is still nonzero, the conversion was partial rather than complete.
ECC vs S/4HANA
LB11 continues to function on S/4HANA when the warehouse is run under classic embedded WM, since the LTBK, LTBP, LTAK and LTAP tables and the transaction itself are part of the compatibility scope carried forward from ECC. There is no Fiori app equivalent for this specific transaction. Warehouses migrated to SAP EWM, whether embedded or decentralized, do not use transfer requirements or transfer orders at all; the whole LB-series and its downstream LT-series counterparts are replaced by warehouse task and warehouse order processing, and LB11 becomes irrelevant rather than modernized.
Common pitfalls and how to diagnose them
- Empty result list: the most common cause is that the requirement has already been fully converted to a transfer order and its open quantity in LTBP is zero, so it no longer meets LB11 selection logic. The second cause is a selection filter that is too narrow, particularly a storage type or movement type restriction that does not match how the requirement was actually created. Check LTBP directly for the material before assuming the requirement never existed.
- Partial conversion mismatch: a requirement line shows a nonzero open quantity after what the user believes was a completed conversion. This happens when the TO was created for less than the full requested quantity, often deliberately to split across two storage bins. Check LTAP for all transfer order items referencing the requirement number and sum the confirmed quantities against the original LTBP request before assuming data corruption.
- Storage bin determination failure: TO creation from the list fails with an error indicating no storage bin was found. This is a configuration gap in the storage type search strategy for the combination of movement type and storage type, not a data problem on the requirement itself. Confirm the movement type actually assigned to the requirement matches what the search strategy configuration expects.
- Lock contention: creation fails or hangs because another user has the same transfer requirement item open in change mode, holding an enqueue lock. This resolves itself when the other session closes; forcibly clearing the lock entry without confirming the other user's work is complete risks a second, conflicting transfer order.
- Reflex fix to avoid: deleting and recreating the transfer requirement when a conversion appears stuck. This does not address an underlying stock or configuration problem and frequently produces an orphan transfer order with no valid link back to the new requirement, making the discrepancy harder to trace afterward.
Whose problem this is
This is functional WM territory, owned by the warehouse management or logistics execution consultant. Basis involvement is limited to clearing a stuck enqueue lock if a session terminated abnormally. A clean handover includes the warehouse number, the material and plant, the specific transfer requirement number reproducing the issue, and whether the problem is an empty list, a partial conversion, or a bin determination error at TO creation.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/lb11ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.