« Mon transfer order va dans le mauvais bin, on comprend pas. » Si tu travailles sur un projet SAP WM, tu as forcément entendu cette phrase. Souvent en Hypercare, parfois en plein audit. Et la grande majorité du temps, le coupable est le même : la storage bin type search, ce 3e tier de la stratégie de putaway que beaucoup de projets configurent à moitié, ou pas du tout.
SAP WM détermine l’emplacement de stockage en cascade : d’abord un type de stockage, puis une section, puis un type de bin. Le 3e tier est le filet de sécurité du putaway. Quand il est mal configuré, tes palettes de produits volumineux finissent dans des bins shelving, et l’opérateur passe son temps à corriger les TO en LT12. Ce filet, je l’ai vu cassé sur des projets warehouse de toutes tailles, du site régional au campus international à 80 000 emplacements.
Dans ce guide, je te détaille le mécanisme à 3 tiers, la config SPRO complète (path + tables T334P/T334B/T334T), un cas concret de putaway de produits volumineux, le troubleshooting des 5 causes les plus fréquentes, et le comparatif avec EWM dans S/4HANA. Si tu lis cet article jusqu’au bout, tu sauras reconfigurer une bin type search proprement, debugger un transfer order qui dérape, et anticiper la migration WM → EWM qui arrive de plus en plus vite.
Pourquoi le 3e tier de search est le maillon oublié du putaway WM
Sur les audits WM que je mène, le scénario revient souvent. Le projet a documenté la Storage Type Search (T334T), parfois la Storage Section Search (T334B), et puis pour la Storage Bin Type Search il y a un Excel vide ou un commentaire « pas activé ». Sauf que le warehouse manager voit des palettes en bins shelving, des picks compliqués, et une productivité qui plafonne.
Un putaway mal optimisé coûte une part significative de la productivité entrepôt sur l’année. La storage bin type search n’est pas un détail technique. C’est une mécanique de filtrage qui paie son ROI dès la première semaine en prod.
Le mécanisme à 3 tiers de SAP WM (théorie + schéma)
SAP WM ne « choisit » pas un bin par magie. Il déroule une cascade de filtres, chacun s’appuyant sur une table SPRO dédiée. Le bin retenu est celui qui satisfait les 3 niveaux simultanément.
Storage Type Search (1er filtre)
SAP regarde d’abord le type de mouvement et le type de stock de l’article. Il consulte la table T334T et trouve une séquence ordonnée de storage types candidats. Exemple typique : pour un mouvement 101 (réception sur stock libre), la séquence sera 001 – High Rack puis 002 – Bulk puis 003 – Picking shelves. SAP retient le premier où il y a de la place. Pour creuser ce 1er tier en détail (5 stratégies standard C/P/F/K/L, configuration SPRO, Storage Type Indicator master article), voir notre guide dédié à la storage type search.
Storage Section Search (2e filtre)
À l’intérieur du storage type retenu, SAP filtre les sections via T334B. C’est ici qu’on encode la logique ABC (fast movers en section A, slow movers en C), ou la séparation par caractéristique produit (température, danger).
Storage Bin Type Search (3e filtre, focus de l’article)
C’est ici que la table T334P entre en scène. SAP regarde le storage unit type du produit (palette EUR, demi-palette, carton master), puis cherche dans la séquence quels bin types peuvent accueillir cette unité. Logique cascade similaire à la détermination de batch en MM/PP, mais appliquée à la dimension physique du bin.
Configuration step-by-step de la storage bin type search
Trois tables, trois transactions, et un flag à activer. Une fois que tu as la mécanique en tête, ça va vite. Ce qui prend du temps, c’est de cadrer correctement les bin types avec ton équipe logistique avant de toucher SPRO.
Chemin SPRO :
Logistics Execution → Warehouse Management → Strategies → Storage Bin Type Search
-
1Définir les bin types (T303)
Liste les types physiques que tu as en entrepôt :
BS= Block Storage,HR= High Rack,SH= Shelving,PB= Pallet Bin. C’est une table master, prends le temps de la cadrer avec ton WMS lead avant SPRO. -
2Définir les storage unit types
Encode les unités logistiques que tu vas mouvementer :
E1= palette EUR,E2= demi-palette,CT= carton master. C’est ce que portera le master article (vue Warehouse Management 1). -
3Affecter les bin types aux storage bins (LS01N / LS02N)
Chaque bin physique reçoit un bin type. Sur les projets brownfield, c’est souvent une mass update SQVI ou LSMW. Vérifie en
LS03Nque tous les bins ont bien un bin type renseigné. -
4Construire la séquence T334P
SPRO > Storage Bin Type Search. Pour chaque combinaison warehouse + storage type + storage unit type, tu listes les bin types acceptables dans l’ordre de préférence. Exemple : pour storage type 002 + SUT E1 (palette EUR), séquence
PB → BS(palette bin d’abord, sinon block storage). -
5Activer le flag dans le storage type
SPRO > Storage Type > flag SUT check active. Sans ce flag, T334P reste lettre morte. C’est le piège #1 que je vois en audit : config impeccable mais flag oublié.
-
6Tester sans casser la prod
Crée une réception MIGO 101 en environnement QAS, vérifie le bin retenu en
LT09(TO display) etLS03N(bin status). Ne pousse en prod qu’après 3 cycles testés sans correction manuelle.
Petite précision côté droits : la config SPRO de WM nécessite un rôle technique dédié (transactions OMM4, OMLY et accès SM30 sur les tables tables T334**). Si tu travailles dans un contexte multi-équipes, vérifie ton rôle PFCG en amont, sinon tu vas perdre 2 jours en aller-retour avec ton admin Basis. J’en parle en détail dans le guide PFCG, SU01, SU53.
Lier la bin type search à une stratégie de putaway
La bin type search ne fonctionne pas seule. Elle est branchée sur la stratégie de putaway définie au niveau du storage type, et SAP WM propose une dizaine de stratégies standard. Les deux plus courantes en projet : P (Putaway via Pallets), qu’on active typiquement sur les storage types de type pallet rack, et F (Fixed Bin), qu’on utilise pour les références à forte rotation auxquelles on assigne un emplacement fixe dans la vue WM2 du master article (le matériel revient toujours au même bin). À côté, tu croiseras aussi I (consolidation sur stock existant du même article), K (cross-docking), L (near fixed bin), B (bulk storage) ou C (open storage) selon le profil d’entrepôt.
Astuce pour les projets multi-storage-types : la séquence T334P peut différer d’un storage type à l’autre. Sur un site avec 5 zones (réception, transit, picking, bulk, retours), tu peux très bien avoir 5 séquences distinctes. Documente-les dans un Excel maître, parce qu’au bout de 6 mois personne ne se souvient pourquoi le storage type 003 prend les bin types SH → CT et le 004 prend CT → SH.
Cas concret : putaway optimisé pour produits volumineux
Imaginons un site avec 3 types de bin : SH (shelving, capacité 1 carton), BS (block storage, capacité 1 palette), PB (pallet bin, capacité 1 palette EUR). Le client met en stock un produit dont l’unité est la palette EUR (SUT E1). Sans bin type search, SAP peut très bien proposer un bin SH trop petit. L’opérateur reçoit un TO impossible à exécuter, le rejette en LT12, et la palette traîne en zone de réception.
Avec la bin type search activée, SAP filtre dès la création du TO. La séquence T334P pour SUT E1 est par exemple PB → BS. SAP cherche d’abord un pallet bin libre, puis si rien, un block storage. Le bin SH est exclu du calcul. Le TO part droit sur un bin adapté.
« La bin type search, c’est le filet de sécurité quand le picker est pressé. Sans elle, tu paies en retours administratifs ce que tu pensais économiser en config. »
Cas particulier : si ton produit est batch-managed (gestion des lots SAP), la bin type search se combine avec la stratégie batch. Tu peux alors avoir une logique « palette en pallet bin + lot le plus ancien d’abord » qui devient ton SOP de picking. C’est la combinaison qui fait gagner le plus en productivité sur les sites pharma ou agro où le FIFO est obligatoire.
Troubleshooting : pourquoi mon transfer order va dans le mauvais bin
Quelques causes récurrentes couvrent la grande majorité des cas que je vois en Hypercare. Si tu débugges un TO qui dérape, déroule cette checklist dans l’ordre.
| Cause | Symptôme | Vérification |
|---|---|---|
| Bin type non affecté au bin physique | TO part dans n’importe quel bin libre | LS03N sur le bin : champ Storage bin type vide |
| Séquence T334P incomplète | TO ignore certains bins valides | SPRO > T334P : ligne manquante pour la combinaison storage type + SUT |
| Storage section masque la bin type | TO part dans bin type non prévu mais section correcte | T334B retourne 0 candidat avant T334P |
| Capacity check non activé | TO part dans bin trop petit malgré T334P OK | OMLY : flag Capacity check vide pour le storage type |
Config T334P correcte
- Ligne pour chaque combinaison storage type + SUT critique
- Bin types listés du plus précis au plus large
- Flag SUT check active coché en OMLY
- Bin types renseignés sur tous les bins en LS03N
Config qui dérape en prod
- T334P avec lignes manquantes ou en désordre
- Flag SUT check active oublié
- Bin types renseignés partiellement (mass update incomplète)
- Customizing non aligné avec les pratiques métier réelles
SAP WM vs SAP EWM (S/4HANA) : ce qui change pour la bin détermination
Si tu lis cet article en 2026, tu travailles probablement sur un projet WM en fin de cycle ou en migration. SAP a annoncé la fin progressive du support pour WM, avec une bascule officielle vers EWM Embedded comme cible S/4HANA. Pour les dates exactes, consulter les SAP Notes de roadmap à jour dans le SAP Support Portal. EWM est le successeur officiel, embarqué dans S/4HANA depuis 1610 ou déployé en decentralized.
La logique conceptuelle des 3 tiers reste, mais l’implémentation est totalement différente. Tu ne migres jamais une config T334P en 1:1 vers EWM. Voici les correspondances que j’utilise en cadrage projet.
À noter : si tu veux rester sur le modèle WM sous S/4HANA sans basculer en EWM, SAP propose le module Stock Room Management. Il préserve les concepts WM (storage type, section, bin, tables T334B/T334P) tout en restant supporté sous S/4HANA. C’est l’option pragmatique pour des entrepôts avec une complexité modérée où EWM serait surdimensionné, le temps de finaliser une roadmap de migration plus large.
| Concept | SAP WM | SAP EWM (S/4HANA) |
|---|---|---|
| Logique de search | 3 tiers en cascade (T334T → T334B → T334P) | Storage Process + Storage Control (paramètrès + activités) |
| Tables centrales | T334P, T334B, T334T | /SCWM/T_PUTAWAY, /SCWM/T_STR_BIN |
| Transactions principales | SPRO + LX02, LS03N, LT09 | SPRO + /SCWM/MON, /SCWM/PRDI |
| Point d’extension | Customizing standard via tables tables T334** | Process-Oriented Storage Control + Storage Process / Storage Control framework |
| Granularité capacité | Bin type + capacity check (poids, volume) | Quant capacity + nested handling units |
| Performance | Bonne sur volume modéré (< 100k bins) | Optimisée pour volumes élevés et flux temps réel |
FAQ : SAP WM storage bin type search
Quelle est la différence entre storage type search et storage bin type search ?
Le storage type search (table T334T) filtre par type de zone de stockage (high rack, bulk, picking). Le storage bin type search (table T334P) filtre, à l’intérieur d’un storage type retenu, par capacité physique du bin (palette, demi-palette, carton). Le premier choisit la zone, le second choisit le bin dans la zone.
Quelle table SAP stocke la configuration de la storage bin type search ?
La table principale est T334P. Elle stocke la séquence de bin types acceptables pour chaque combinaison warehouse + storage type + storage unit type. Tu peux la consulter en SM30 ou la maintenir via SPRO (Logistics Execution > WM > Strategies > Storage Bin Type Search).
Comment activer la bin type search dans une stratégie de putaway ?
Deux conditions cumulatives : (1) la séquence T334P doit être renseignée pour ta combinaison storage type + SUT, (2) le flag SUT check active doit être coché au niveau du storage type (transaction OMLY ou SPRO > Storage Type). Sans ce flag, T334P est ignorée même si elle est parfaitement remplie.
Pourquoi mon transfer order va dans le mauvais bin malgré ma config T334P ?
5 causes couvrent la grande majorité des cas : flag SUT check active oublié, bin types non affectés aux bins physiques (vérif LS03N), séquence T334P incomplète, un userexit custom qui override le standard, ou capacity check désactivé. Déroule la checklist troubleshooting dans cet ordre, tu trouves la cause en moins de 30 minutes.
Peut-on avoir plusieurs bin types dans un même storage type ?
Oui, et c’est même le cas le plus courant. Un storage type 002 (block storage par exemple) peut contenir des bin types BS pour les palettes EUR et HB pour les half pallets. La séquence T334P définit alors quel bin type retenir en priorité selon le SUT du produit reçu.
Quelle différence entre SAP WM et SAP EWM pour la bin détermination ?
WM utilise un mécanisme à 3 tiers basé sur des tables (T334T/S/B). EWM utilise les Storage Process et Storage Control, qui sont plus paramétrables mais aussi plus complexes. La logique conceptuelle (filtre cascade) reste, mais l’implémentation diffère totalement. La BAdI EWM s’appelle Storage Control framework. Une migration WM → EWM ne se fait jamais en 1:1.
Comment tester ma config T334P sans toucher à la prod ?
Reproduis le cas en QAS avec un MIGO 101 sur un article test. Vérifie le TO créé en LT09 (display TO) et le bin retenu en LS03N. Tu peux aussi simuler la création de TO en LT04 avec l’option foreground pour voir SAP dérouler la cascade des 3 tiers en temps réel. Compte 3 cycles de tests minimum avant de valider.
Quand utiliser un userexit custom ?
En dernier recours, quand une règle métier dépasse ce que le standard sait exprimer (contraintes de distance, segregation de produits dangereux, logique propre à un site). Le code custom WM est lourd à maintenir et casse souvent en montée de version SAP. Avant de coder, vérifie qu’une combinaison storage section + bin type ne suffit pas. le plus souvent, le standard couvre.
Conclusion : la bin type search, un détail qui paie son ROI vite
La storage bin type search n’est pas glamour. Pas de transaction nouvelle, pas de fonctionnalité S/4HANA brillante. Mais c’est le 3e tier qui transforme un putaway approximatif en putaway industriel. Sur les sites où je l’ai cadrée correctement avec les équipes warehouse, on a vu la productivité opérateur progresser nettement, et les corrections manuelles en LT12 chuter sensiblement.
3 takeaways à retenir :
- Le 3e tier (T334P) est obligatoire pour un putaway robuste. Sans bin type search, ton site fonctionne au feeling.
- Le flag SUT check active au niveau du storage type est le piège #1. Vérifie-le avant tout autre debug.
- EWM Embedded remplace WM à terme selon la roadmap S/4HANA officielle. La logique 3 tiers survit, l’implémentation change. Anticipe la migration dans tes choix de design WM aujourd’hui.
À lire ensuite
SAP WM 2-step picking : configurer la cascade pick / allocation pour les entrepôts à fort volume
SAP WM 2 Step Picking : cascade picking-allocation, configuration SPRO 3 niveaux, cas concret end-to-end, pièges hypercare et migration EWM.
Michael A.
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.
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.