Transfer Requirement Stuck Without a Transfer Order

The warehouse team reports that a delivery or production order shows as relevant for picking but nothing appears on the picker's list, or that goods issue cannot be posted because the transfer order is missing. Someone checks the delivery and finds it has already reserved stock and generated a transfer requirement, but there is no transfer order number against it. It often surfaces at shift change, when the picker asks why a delivery from the previous shift never got a pick document, or during month end when a batch of deliveries is found sitting in the same unconverted state. The immediate assumption is that the delivery is broken or that WM 'lost' the document, and the first call is usually to have someone create the transfer order manually so the truck does not miss its slot.

Select all transfer requirements in LT21 for the affected warehouse number over a date range with no transfer order reference, grouped by movement type and storage type. Compare the creation timestamp of each against the last successful run time of the automatic conversion job in SM37 job logs. A cluster tied to one movement type points to configuration; a cluster with no correlation to the job schedule but a shared storage type points to bin determination failure, confirmed by matching application log entries in SLG1 for the same timestamps.

If the movement type is simply not flagged for immediate creation, decide whether that is intended process design or a configuration gap; changing the flag is a config change requiring transport and must be checked against every process that shares the movement type, since flipping it globally can force automatic creation where a manual review step was deliberate. If the background job is not scheduled or has stopped, that is an operational fix owned by job scheduling: reschedule or correct the variant, then reprocess the backlog of open transfer requirements once the job is confirmed running. If storage type search or stock availability is the cause, the transfer order will still not create automatically until the bin determination strategy or the stock status is corrected; forcing a manual transfer order at this point risks placing stock in the wrong storage type or picking from blocked stock, so the underlying storage type sequence or stock release should be fixed first, which is master data or a strategy customizing change depending on scope. If the delivery is blocked, resolve the block through its owning process (credit management, billing) and let the standard flow retrigger creation rather than working around it in WM.

The reflex response is to create the missing transfer order manually for the affected delivery and move on, because it clears the immediate blockage and gets the truck loaded. It does nothing to explain why the automatic step failed, so the same pattern reappears on the next delivery through the same movement type or storage type, and each occurrence gets fixed manually rather than diagnosed, until someone notices a growing backlog of transfer requirements that were all patched the same way and none of the real cause was ever addressed.

Configuration of movement types and storage type search belongs to the WM/EWM process configuration team. Background job scheduling and failures belong to Basis job monitoring, escalated jointly if the job itself is healthy but the variant is wrong. The handover note should state the movement type and warehouse number affected, whether the missing step is configuration or scheduling, the volume of open transfer requirements found, and whether any were closed manually in the interim.