Picking Proposes the Wrong Storage Bin

The warehouse team reports that the pick list or RF task sends the operator to a bin that is empty, or to a bin holding the wrong batch, while the material they know is available sits untouched two aisles over. Sometimes it surfaces as a confirmation error because the proposed bin has less stock than the task requires. Sometimes it is quieter: the pick works, but from a bin the site deliberately avoids for that material, so it looks like the system is ignoring an agreement the warehouse thought was in place. It usually gets escalated as data corruption in the bin, or as the stock overview being wrong, before anyone checks whether the removal logic behind the transfer order was ever set up the way the floor assumes it was.

In order of how often each one is actually the cause once the symptom is confirmed as a strategy problem rather than a data problem.

Confirm the physical picture first, then work back through the strategy layers rather than starting in customizing.

Pull LX03 for the storage type and material to show the quant sitting in the bin the warehouse expected, then pull LT21 for the transfer order that proposed a different bin, and lay the two side by side with the storage type search sequence and the strategy indicator from customizing. The gap between where the stock physically is and what the strategy is configured to consider is the proof, and it needs no interpretation once shown.

If the stock removal strategy indicator or the storage type search sequence is wrong, that is a customizing change owned by the warehouse structure config and requires a transport, coordinated with the WM or EWM lead because it affects every pick against that storage type and movement type combination, not just the one order that surfaced the complaint. If the fixed bin on the material master is stale, that is a data fix: update the WM view or the EWM product location record to the current bin, or physically move the stock back to the bin the master data expects, whichever the warehouse actually wants. If a stock category or special stock indicator is excluding the quant, that is a data or process decision, not a config bug, resolved by releasing the block or correcting the stock category through the appropriate movement. In EWM, a stale slotting result is fixed by rerunning slotting for the product, which is a data action, while a wrong putaway or removal control indicator on the storage type is config and needs a transport.

The reflex fix is to manually override the bin on the transfer order or warehouse task, either by re-entering it directly or by cancelling and recreating the pick against the bin the operator wants. It clears the immediate delivery but leaves the strategy, the sequence, or the fixed bin assignment exactly as broken as before, so the next order for the same material reproduces the same complaint. A second common reflex, changing the storage type's removal strategy to manual picking to make the symptom disappear, quietly breaks automated picking for every other material in that storage type.

Customizing changes to strategy indicators and search sequences belong to the WM or EWM configuration owner; fixed bin corrections and stock category cleanup belong to the warehouse master data team. The handover note should carry the storage type, movement type, the strategy indicator in effect, the bin the master data expected versus the bin the quant occupied, and whether the fix applied was config, transport-bound, or a one-time data correction.