Tu gères un entrepôt SAP WM qui sort 200 lignes de livraison par jour, et tes caristes parcourent les mêmes allées trois fois pour préparer trois commandes différentes. Le 2-step picking existe précisément pour ça : tu sépares la sortie de stock du dispatch par commande, et tu collectes en un seul passage tout ce qu’il faut pour le batch de deliveries du créneau, puis tu ventiles dans une seconde étape vers chaque destination finale.
Sur le papier, c’est trivial. En projet, ça coince à chaque fois sur les mêmes pièges : storage type interim mal dimensionné, recherche de storage type mal configurée pour l’opération 2, deliveries trop hétérogènes pour bénéficier du regroupement. Je te déroule ici la configuration complète, le cas concret de bout en bout, et les pièges terrain que j’ai croisés sur les déploiements WM multi-sites.
2-step picking en SAP WM, définition concrète
Dans un picking en une seule étape, chaque transfer order matérialise une commande client : un cariste va chercher les références d’une delivery donnée, les amène sur le quai d’expédition, et la livraison est traitée. Si tu as trente deliveries à préparer dans le créneau de 14h, tu génères trente transfer orders, et tes caristes font trente fois le tour de l’entrepôt.
Le 2-step picking change la logique de bout en bout. La première étape, le pick, regroupe tous les besoins du créneau : si les trente deliveries demandent au total 12 références différentes pour un total de 480 pièces, tu génères un seul transfer order collectif qui sort ces 480 pièces des bins de stockage et les amène dans une zone tampon, typiquement un Storage Type dédié comme 200. La seconde étape, l’allocation, ventile depuis cette zone tampon : un TO par delivery, qui prend la quantité prévue pour chaque commande et la dépose sur le quai d’expédition correspondant.
Ce découplage a une conséquence forte : le cariste qui fait le pick n’a pas besoin de savoir à quelle delivery iront ces 480 pièces. Il sort ce qu’il faut, point. La logique métier de dispatch est portée par l’allocation, qui se fait souvent à proximité du quai et qui peut être pilotée par un autre profil d’opérateur. Tu gagnes en productivité côté pick (moins de déplacements, parcours optimisé sur les bins) et tu gagnes en précision côté dispatch (vérification sur table de tri en zone tampon avant de poser sur le quai final).
Quand le 2-step picking justifie sa mise en place
Le 2-step picking n’est pas un gain automatique. Il devient pertinent quand trois conditions se cumulent : un volume de deliveries simultanées suffisant pour que le regroupement réduise vraiment les trajets, un mix de références où plusieurs commandes partagent des articles communs, et une organisation physique de l’entrepôt qui sépare clairement la zone de stockage de la zone de dispatch.
Cas où le 2-step apporte un vrai gain
- Plus de 50 deliveries par créneau d’expédition avec articles partagés.
- Entrepôt grande hauteur avec déplacements coûteux par delivery.
- Mix produit où une référence revient dans dix à trente commandes par jour.
- Quai d’expédition à proximité d’une zone de tri sécurisée.
- Pic d’activité matinal type e-commerce où la productivité par cariste devient critique.
Cas où le 2-step ajoute plus de complexité que de gain
- Faible volume avec moins de dix deliveries simultanées.
- Articles très spécifiques par commande sans recouvrement entre deliveries.
- Lots à tracer où chaque batch est figé sur une commande en amont.
- Pas de zone tampon disponible physiquement entre stock et quai.
- Articles dangereux ou réglementés qui ne supportent pas le transit en zone interim.
Avant de basculer en 2-step, fais l’exercice sur un échantillon réel : prends une journée typique, extrais les deliveries du créneau le plus chargé, et regarde combien de références sont partagées entre commandes. Si le ratio référence/delivery est proche de 1, tu n’as rien à regrouper, et le 2-step ajoute une zone tampon et un TO supplémentaire pour rien.
Configuration SAP WM en 5 étapes
La configuration du 2-step picking se fait dans deux familles SPRO distinctes selon que ton déclencheur est un transfer requirement (TR) ou une delivery. Dans la pratique des projets WM, on active généralement les deux pour couvrir les Posting Change Notices et les sorties commerciales.
-
1
Activer le 2-step picking pour les transfer requirements
Chemin SPRO :
Logistic Execution → Warehouse Management → Activities → Transfers → Set up 2-step picking process for Transfer Requirement
Tu y trouves deux sous-points : Transfer Requirement Control et Transfer Type Control. Le premier active le 2-step pour les types de TR (par exemple le type qui pilote les PCN). Le second définit le comportement du transfer type qui sera utilisé pour la collecte vers la zone interim.
Le nœud SPRO « Set up 2-step picking process for Transfer Requirement » ouvre deux entrées : le contrôle du TR et le contrôle du transfer type associé. 
Transfer Requirement Control : chaque TR type que tu veux rendre éligible au 2-step doit être coché ici. Pense aux TR de type rebooking si tu traites des PCN. 
Transfer Type Control : le transfer type utilisé pour le pick doit être configuré pour ouvrir un mouvement vers la zone interim, pas vers le quai final. -
2
Activer le 2-step picking pour le shipping
Chemin SPRO :
Logistic Execution → Shipping → Picking → Define Relevance for Two-step Picking
C’est le pendant côté flux delivery. Tu définis ici sur quel niveau (route, shipping point, warehouse) le 2-step doit être déclenché. Le réglage le plus courant est par warehouse number plus shipping point, ce qui permet de garder du 1-step pour les flux qui ne s’y prêtent pas (sorties express, sorties techniques).
L’écran d’activation côté shipping : choisis la granularité qui correspond à la réalité opérationnelle de tes flux d’expédition. 
Détail du customizing shipping : tu peux activer le 2-step pour une combinaison warehouse / shipping point précise, ce qui isole les flux concernés. -
3
Configurer la recherche de Storage Type pour l’opération 2
Chemin SPRO :
Logistic Execution → Warehouse Management → Strategies → Activate Storage Type Search
C’est ici que tu indiques où SAP doit déposer les pièces du pick : tu crées une entrée avec l’opération
2(qui correspond au 2-step interim) et tu renseignes le Storage Type cible, par convention200dans la plupart des projets, mais ça peut être n’importe quel Storage Type que tu auras défini comme zone tampon.
Storage Type Search avec opération 2 : la combinaison (warehouse, storage type search indicator, opération 2) pointe vers le storage type interim de ton 2-step. Si tu veux comprendre en détail comment la séquence de recherche s’imbrique avec les autres tiers (storage section, storage bin type), regarde l’article dédié à la Storage Type Search SAP WM. Le 2-step n’est qu’une opération parmi d’autres dans la même table de stratégie.
-
4
Activer le flag sur la fiche article (WM view 1)
Si tu veux que le 2-step se déclenche uniquement pour certains articles, tu actives le flag « 2-step picking relevant » dans la vue Warehouse Management 1 du master article. C’est utile quand tu cohabites entre flux 1-step et 2-step sur le même entrepôt : tu peux ainsi exclure les articles très volumineux qui ne supportent pas un transit en zone interim.
Vue WM 1 du master article : le flag « 2-step picking » conditionne la prise en compte de l’article dans le regroupement. -
5
Vérifier la cohérence avec la cascade Section et Bin Type
Le 2-step picking ne vit pas isolé du reste de la stratégie WM. Si tu as activé une Storage Section Search ou un Storage Bin Type Search sur le storage type interim, vérifie que la combinaison reste cohérente. Le piège classique : la zone
200a hérité d’une stratégie de section qui n’a aucun sens en interim, et SAP refuse de créer le TO. Désactive section et bin type search sur le storage type interim si tu n’as pas un besoin métier précis qui les justifie.
Cas concret end-to-end : du PCN à la livraison expédiée
Voici comment ça se déroule en exécution, sur un exemple où le déclencheur est une série de deliveries commerciales. Le scénario est volontairement minimaliste pour que tu reconnaisses chaque écran. Tu trouveras la même séquence en remplaçant VL06P par LT41 si ton déclencheur est un transfer requirement (typiquement un Posting Change Notice après rebooking de stock).
-
1
Créer le groupe depuis les deliveries
Transaction
VL06P. Tu sélectionnes les outbound deliveries du créneau (filtre sur shipping point, route, planned goods issue date) puis tu utilises la fonction « Create Group » du menu. SAP te demande de nommer le groupe et d’attribuer un usage : pour le 2-step picking, c’est l’usage standard de regroupement.
VL06P : la liste des deliveries éligibles, filtrée sur le shipping point. Tu sélectionnes les lignes qui partageront le même groupe de pick. 
Création du groupe : c’est ce numéro qui va piloter le pick collectif puis l’allocation par delivery dans la suite du processus. -
2
Afficher le groupe et déclencher le pick
Transaction
LX39. L’écran de sélection te demande le warehouse et le numéro de groupe. Une fois validé, tu obtiens l’écran de pilotage 2-step avec deux sections distinctes : Pick en haut, Allocation en bas. Tu commences par la section Pick.
LX39 : la sélection demande le warehouse number et le numéro de groupe. Tu peux aussi filtrer par statut de TO si tu reprends un traitement. 
Section Pick de LX39 : la liste consolidée de toutes les références à sortir, agrégée par bin source. SAP a fusionné les besoins des deliveries du groupe. -
3
Générer le transfer order de pick
Toujours dans LX39, depuis la section Pick, tu déclenches la création du transfer order collectif. SAP génère un seul TO qui va sortir l’ensemble des pièces du créneau et les amener dans la zone interim, le Storage Type
200de ton customizing.
Transfer order de pick : un seul TO pour tout le créneau, qui consolide les bins source et désigne la zone interim comme destination. -
4
Confirmer le pick côté entrepôt
Une fois le cariste passé sur les bins source et arrivé en zone interim, le TO est confirmé via
LT12ou directement depuis LX39. La confirmation matérialise le transfert physique : le stock disparaît des bins source et apparaît dans le storage type 200.
Confirmation du TO de pick : la quantité collectée est désormais visible dans la zone interim et disponible pour l’étape d’allocation. 
Écran de confirmation : pour les flux radiofréquence, cette étape est faite directement depuis le terminal mobile sans repasser par la GUI. 
Statut Pick OK : le groupe est marqué comme prêt pour l’allocation. La cascade peut continuer. -
5
Dispatcher avec l’allocation
Retour dans LX39, section Allocation cette fois. Tu génères un transfer order par delivery, qui prend depuis la zone interim la quantité destinée à chaque commande et la dépose dans la zone de préparation finale (généralement un autre storage type interim, comme la zone 916 ou 902 selon ton paramétrage). Confirmation via LT12 et tu peux enchaîner sur le post goods issue côté delivery.
L’élégance du modèle, c’est que tu peux paralléliser les deux étapes : pendant qu’un cariste fait le pick du créneau suivant, un opérateur en zone interim alloue le créneau précédent. Le débit théorique grimpe, à condition que ta zone interim soit dimensionnée pour absorber l’écart temporel entre les deux opérations.
Pièges terrain à anticiper
Au-delà de ce check de base, voici les trois pièges qui reviennent le plus souvent en projet :
Zone interim saturée. Si la cadence de pick est plus rapide que la cadence d’allocation, le storage type 200 sature, et les nouveaux TO de pick sont bloqués faute de bin disponible. C’est typiquement ce qui arrive quand tu lances le 2-step sans avoir audité la capacité physique de la zone tampon. Règle pratique : dimensionne la zone interim pour absorber au moins deux créneaux d’expédition.
Confusion entre groupe shipping et groupe pick. SAP utilise le mot « group » à plusieurs endroits. Le groupe que tu manipules en VL06P est un regroupement de deliveries pour pilotage 2-step. Il ne se confond pas avec un wave (qui est une autre logique de regroupement, plus orientée planning). Si ton entrepôt utilise déjà des waves, vérifie que le groupe 2-step ne casse pas la logique wave existante.
Articles à lot ou date de péremption. Si tu fais du FIFO ou de la gestion par batch determination sur les articles concernés, vérifie que la détermination du lot est faite au niveau du transfer order de pick et pas au niveau de la delivery. Sinon, deux deliveries qui demandent le même article peuvent se retrouver avec des lots différents alors qu’elles auraient dû partager le même lot, et tu casses ta logique FEFO sans t’en apercevoir.
2-step picking en WM et en EWM, les différences clés
Une idée fausse circule beaucoup : que le 2-step picking serait une spécificité du WM legacy, et qu’EWM ne le proposerait pas. C’est faux. EWM propose son propre 2-step picking, dans un cadre plus moderne. Voici ce qui change quand tu passes de l’un à l’autre.
Concrètement, sur un projet de migration WM vers EWM, le 2-step picking n’est jamais un mapping 1:1. Tu rejoues le besoin métier (pourquoi tu fais du 2-step) avant de regarder comment EWM le porte techniquement. Et tu profites de la migration pour rebrasser des choix de conception qui dataient parfois de plus de dix ans.
« Le 2-step picking, c’est avant tout une décision d’organisation d’entrepôt. SAP WM ou EWM ne fait que matérialiser un choix qui doit d’abord avoir été pris côté opérations. »
FAQ : 2-step picking SAP WM
Le storage type interim doit-il obligatoirement être le 200 ?
Non. Le 200 est une convention héritée des exemples SAP, mais tu peux utiliser n’importe quel storage type que tu aurais défini comme zone tampon. L’important est que ce storage type soit déclaré dans la Storage Type Search pour l’opération 2, et qu’il soit configuré comme zone interim (pas comme zone de stockage long terme).
Peut-on faire du 2-step picking sans passer par un groupe ?
Techniquement non, le groupe est le pivot du modèle 2-step en WM. Mais tu peux automatiser sa création : un job batch qui exécute VL06P avec une variante figée crée le groupe automatiquement à chaque créneau d’expédition, sans intervention utilisateur. La plupart des entrepôts en production fonctionnent ainsi.
Que se passe-t-il si une delivery du groupe est annulée après le pick ?
Le stock sorti reste en zone interim et doit être reposté manuellement vers son storage type d’origine, typiquement via un mouvement 850/851 ou un transfer order ad hoc. C’est une opération de remise en stock qu’il faut documenter dans la procédure opérationnelle, parce qu’elle est invisible côté delivery (qui est déjà annulée) et peut générer du stock fantôme en zone tampon si elle est oubliée.
Le 2-step picking est-il compatible avec la radiofréquence ?
Oui, totalement. Les deux étapes (pick et allocation) peuvent être confirmées en RF via les transactions standards. C’est même là que le 2-step prend tout son sens : le pick collectif optimisé par parcours bin et la confirmation immédiate sur terminal mobile font gagner du temps à chaque cycle.
Faut-il un Storage Section Search dédié sur le storage type interim ?
Dans la grande majorité des cas, non. La zone interim est une zone de transit, pas une zone de stockage différencié. Si tu actives un Storage Section Search sur le storage type 200 sans besoin métier précis, tu risques de bloquer la création des TO de pick par incompatibilité de stratégie. Désactive section et bin type search sur la zone interim sauf cas particulier (par exemple séparation physique des articles dangereux en zone tampon).
2-step picking et cascade WM, comment les articuler
Le 2-step picking est un cas particulier de la mécanique générale de Storage Type Search en SAP WM. Si tu veux comprendre comment la cascade Storage Type → Storage Section → Storage Bin Type s’imbrique dans la stratégie globale d’un warehouse, regarde l’article sur la Storage Type Search SAP WM, qui explique le tier 1 dans le détail, et celui sur la Storage Section Search, qui couvre le tier 2. Pour le tier 3 sur les types de bins, l’article Storage Bin Type Search ferme la boucle.
Le 2-step picking, lui, vit au croisement de la stratégie de Storage Type et du flux delivery / transfer requirement. C’est un patron simple en apparence mais qui demande une vraie discipline d’exploitation : zone interim dimensionnée, cadence pick / allocation équilibrée, et procédures d’exception (annulations, ruptures) bien rodées. Quand ces trois conditions sont en place, le gain de productivité est immédiat et mesurable dès les premières semaines.
À lire ensuite
SAP WM storage section search : configurer le tier 2 du putaway (T334B)
Storage Section Search SAP WM (T334B) : configuration SPRO, écran 5 colonnes, activation Storage Type, cas concret Goods Issue MIGO/LB10, passage EWM.
Michael A.
SAP WM storage type search : configurer le tier 1 du putaway
Guide complet de la storage type search SAP WM : configuration SPRO, écran de stratégie pas à pas (10 colonnes réelles), assignation au master article (vue WM1), cas concret MIGO/LB10/TO...
Michael A.
SAP WM storage bin type search : guide complet (2026)
Guide complet de la storage bin type search SAP WM : mecanisme a 3 tiers, configuration SPRO (T334P/T334B/T334T), troubleshooting des 5 causes les plus frequentes, et comparatif avec EWM dans...
Michael A.
Synchronisation des données entre SAP ERP et EWM : embedded, décentralisé et le rôle du CIF, ALE et DRF
Synchronisation des données entre SAP ERP et EWM : partage en embedded, transfert CIF/ALE/DRF en décentralisé, et ce qui se crée à la main vs en background.
Michael A.