“My transfer order is going to the wrong bin, and we can’t figure out why.” If you work on an SAP WM project, you’ve definitely heard this sentence. Often during Hypercare, sometimes mid-audit. And the vast majority of the time, the culprit is the same one: the storage bin type search, that third tier of the putaway strategy that many projects configure halfway, or not at all.
SAP WM determines the storage location as a cascade: first a storage type, then a section, then a bin type. The third tier is the safety net of putaway. When it’s misconfigured, your pallets of bulky products end up in shelving bins, and the operator spends their time fixing TOs in LT12. I’ve seen that safety net broken on warehouse projects of every size, from the regional site to the international campus with 80,000 bins.
In this guide, I walk you through the 3-tier mechanism, the full SPRO setup (path + tables T334P/T334B/T334T), a real putaway case for bulky products, troubleshooting the 5 most common causes, and the comparison with EWM in S/4HANA. If you read this article to the end, you’ll know how to reconfigure a bin type search cleanly, debug a transfer order that goes off the rails, and anticipate the WM to EWM migration that’s coming faster and faster.
Why the third search tier is the forgotten link in WM putaway
On the WM audits I run, the scenario comes up again and again. The project documented the Storage Type Search (T334T), sometimes the Storage Section Search (T334B), and then for the Storage Bin Type Search there’s an empty spreadsheet or a note saying “not activated.” Except the warehouse manager sees pallets in shelving bins, awkward picks, and productivity hitting a ceiling.
A poorly optimized putaway costs a significant share of warehouse productivity over the year. The storage bin type search isn’t a technical detail. It’s a filtering mechanism that pays back its ROI in the very first week in production.
The 3-tier mechanism of SAP WM (theory + diagram)
SAP WM doesn’t “pick” a bin by magic. It runs through a cascade of filters, each one relying on a dedicated SPRO table. The chosen bin is the one that satisfies all 3 levels at once.
Storage Type Search (1st filter)
SAP first looks at the movement type and the stock type of the material. It checks table T334T and finds an ordered sequence of candidate storage types. A typical example: for a 101 movement (goods receipt into unrestricted stock), the sequence will be 001 – High Rack, then 002 – Bulk, then 003 – Picking shelves. SAP keeps the first one with available space. To dig into this first tier in detail (the 5 standard strategies C/P/F/K/L, SPRO configuration, the Storage Type Indicator on the material master), see our dedicated guide to the storage type search.
Storage Section Search (2nd filter)
Within the chosen storage type, SAP filters the sections via T334B. This is where you encode the ABC logic (fast movers in section A, slow movers in C), or the separation by product characteristic (temperature, hazard).
Storage Bin Type Search (3rd filter, the focus of this article)
This is where table T334P comes into play. SAP looks at the product’s storage unit type (EUR pallet, half-pallet, master carton), then searches the sequence for which bin types can hold that unit. The cascade logic is similar to batch determination in MM/PP, but applied to the bin’s physical dimension.
Step-by-step configuration of the storage bin type search
Three tables, three transactions, and one flag to activate. Once you have the mechanism in your head, it goes quickly. What takes time is framing the bin types correctly with your logistics team before you touch SPRO.
SPRO path:
Logistics Execution → Warehouse Management → Strategies → Storage Bin Type Search
-
1Define the bin types (T303)
List the physical types you have in the warehouse:
BS= Block Storage,HR= High Rack,SH= Shelving,PB= Pallet Bin. This is a master table, so take the time to frame it with your WMS lead before SPRO. -
2Define the storage unit types
Encode the logistics units you’ll move:
E1= EUR pallet,E2= half-pallet,CT= master carton. This is what the material master will carry (Warehouse Management 1 view). -
3Assign the bin types to the storage bins (LS01N / LS02N)
Each physical bin gets a bin type. On brownfield projects, this is often a mass update via SQVI or LSMW. Check in
LS03Nthat every bin actually has a bin type filled in. -
4Build the T334P sequence
SPRO > Storage Bin Type Search. For each combination of warehouse + storage type + storage unit type, you list the acceptable bin types in order of preference. Example: for storage type 002 + SUT E1 (EUR pallet), the sequence is
PB → BS(pallet bin first, otherwise block storage). -
5Activate the flag in the storage type
SPRO > Storage Type > SUT check active flag. Without this flag, T334P stays a dead letter. It’s the #1 trap I see in audits: a flawless config but a forgotten flag.
-
6Test without breaking production
Create a MIGO 101 goods receipt in your QAS environment, then check the chosen bin in
LT09(TO display) andLS03N(bin status). Only push to production after 3 cycles tested with no manual correction.
A quick note on authorizations: the WM SPRO configuration needs a dedicated technical role (transactions OMM4, OMLY and SM30 access to the T334** tables). If you work in a multi-team context, check your PFCG role up front, otherwise you’ll lose 2 days going back and forth with your Basis admin. I cover this in detail in the PFCG, SU01, SU53 guide.
Linking the bin type search to a putaway strategy
The bin type search doesn’t work on its own. It’s wired to the putaway strategy defined at the storage type level, and SAP WM offers about a dozen standard strategies. The two most common on projects: P (Putaway via Pallets), which you typically activate on pallet-rack storage types, and F (Fixed Bin), which you use for high-turnover materials that you assign to a fixed bin in the material master’s WM2 view (the material always comes back to the same bin). Alongside those, you’ll also run into I (consolidation onto existing stock of the same material), K (cross-docking), L (near fixed bin), B (bulk storage), or C (open storage) depending on the warehouse profile.
A tip for multi-storage-type projects: the T334P sequence can differ from one storage type to another. On a site with 5 zones (receiving, transit, picking, bulk, returns), you can perfectly well have 5 distinct sequences. Document them in a master spreadsheet, because after 6 months nobody remembers why storage type 003 takes bin types SH → CT and 004 takes CT → SH.
A concrete case: optimized putaway for bulky products
Let’s picture a site with 3 bin types: SH (shelving, capacity 1 carton), BS (block storage, capacity 1 pallet), PB (pallet bin, capacity 1 EUR pallet). The customer puts away a product whose unit is the EUR pallet (SUT E1). Without a bin type search, SAP can easily propose an SH bin that’s too small. The operator gets a TO that’s impossible to execute, rejects it in LT12, and the pallet sits in the receiving area.
With the bin type search activated, SAP filters right from TO creation. The T334P sequence for SUT E1 is, for example, PB → BS. SAP first looks for a free pallet bin, then, if there’s nothing, a block storage. The SH bin is excluded from the calculation. The TO goes straight to a suitable bin.
“The bin type search is the safety net for when the picker is in a hurry. Without it, you pay in administrative rework what you thought you’d save on config.”
A special case: if your product is batch-managed (SAP batch management), the bin type search combines with the batch strategy. You can then have a “pallet in a pallet bin + oldest batch first” logic that becomes your picking SOP. It’s the combination that delivers the biggest productivity gains on pharma or food sites where FIFO is mandatory.
Troubleshooting: why my transfer order goes to the wrong bin
A handful of recurring causes cover the vast majority of the cases I see in Hypercare. If you’re debugging a TO that goes off the rails, run through this checklist in order.
| Cause | Symptom | Check |
|---|---|---|
| Bin type not assigned to the physical bin | TO goes to any free bin | LS03N on the bin: Storage bin type field is empty |
| Incomplete T334P sequence | TO skips some valid bins | SPRO > T334P: missing row for the storage type + SUT combination |
| Storage section masks the bin type | TO goes to an unexpected bin type but the right section | T334B returns 0 candidates before T334P |
| Capacity check not activated | TO goes to a bin that’s too small despite T334P being OK | OMLY: Capacity check flag empty for the storage type |
A correct T334P config
- A row for every critical storage type + SUT combination
- Bin types listed from the most specific to the broadest
- SUT check active flag checked in OMLY
- Bin types filled in on every bin in LS03N
A config that goes wrong in production
- T334P with missing or out-of-order rows
- SUT check active flag forgotten
- Bin types only partly filled in (incomplete mass update)
- Customizing not aligned with the real business practices
SAP WM vs SAP EWM (S/4HANA): what changes for bin determination
If you’re reading this article in 2026, you’re probably working on a WM project that’s near end of life or in migration. SAP has announced the gradual end of support for WM, with an official move to Embedded EWM as the S/4HANA target. For the exact dates, check the up-to-date roadmap SAP Notes in the SAP Support Portal. EWM is the official successor, embedded in S/4HANA since 1610 or deployed as decentralized.
The conceptual 3-tier logic stays, but the implementation is completely different. You never migrate a T334P config 1:1 to EWM. Here are the mappings I use when framing a project.
One note: if you want to stay on the WM model under S/4HANA without moving to EWM, SAP offers the Stock Room Management module. It preserves the WM concepts (storage type, section, bin, tables T334B/T334P) while remaining supported under S/4HANA. It’s the pragmatic option for warehouses with moderate complexity where EWM would be oversized, while you finalize a broader migration roadmap.
| Concept | SAP WM | SAP EWM (S/4HANA) |
|---|---|---|
| Search logic | 3 tiers in a cascade (T334T → T334B → T334P) | Storage Process + Storage Control (parameters + activities) |
| Core tables | T334P, T334B, T334T | /SCWM/T_PUTAWAY, /SCWM/T_STR_BIN |
| Main transactions | SPRO + LX02, LS03N, LT09 | SPRO + /SCWM/MON, /SCWM/PRDI |
| Extension point | Standard customizing via the T334** tables | Process-Oriented Storage Control + Storage Process / Storage Control framework |
| Capacity granularity | Bin type + capacity check (weight, volume) | Quant capacity + nested handling units |
| Performance | Good for moderate volumes (< 100k bins) | Optimized for high volumes and real-time flows |
FAQ: SAP WM storage bin type search
What’s the difference between the storage type search and the storage bin type search?
The storage type search (table T334T) filters by storage zone type (high rack, bulk, picking). The storage bin type search (table T334P) filters, within a chosen storage type, by the bin’s physical capacity (pallet, half-pallet, carton). The first one picks the zone, the second one picks the bin within the zone.
Which SAP table stores the storage bin type search configuration?
The main table is T334P. It stores the sequence of acceptable bin types for each warehouse + storage type + storage unit type combination. You can view it in SM30 or maintain it via SPRO (Logistics Execution > WM > Strategies > Storage Bin Type Search).
How do you activate the bin type search in a putaway strategy?
Two cumulative conditions: (1) the T334P sequence must be filled in for your storage type + SUT combination, (2) the SUT check active flag must be checked at the storage type level (transaction OMLY or SPRO > Storage Type). Without this flag, T334P is ignored even if it’s perfectly filled in.
Why does my transfer order go to the wrong bin despite my T334P config?
5 causes cover the vast majority of cases: a forgotten SUT check active flag, bin types not assigned to the physical bins (check LS03N), an incomplete T334P sequence, a custom user exit that overrides the standard, or a deactivated capacity check. Run through the troubleshooting checklist in this order and you’ll find the cause in under 30 minutes.
Can you have several bin types within the same storage type?
Yes, and it’s actually the most common case. A storage type 002 (block storage, for example) can hold BS bin types for EUR pallets and HB for half-pallets. The T334P sequence then defines which bin type to choose first based on the SUT of the incoming product.
What’s the difference between SAP WM and SAP EWM for bin determination?
WM uses a 3-tier mechanism based on tables (T334T/S/B). EWM uses Storage Processes and Storage Control, which are more configurable but also more complex. The conceptual logic (cascade filter) stays, but the implementation is completely different. The EWM equivalent is the Storage Control framework. A WM to EWM migration is never done 1:1.
How do you test your T334P config without touching production?
Reproduce the case in QAS with a MIGO 101 on a test material. Check the TO created in LT09 (display TO) and the chosen bin in LS03N. You can also simulate TO creation in LT04 with the foreground option to watch SAP run through the 3-tier cascade in real time. Plan for at least 3 test cycles before you sign off.
When should you use a custom user exit?
As a last resort, when a business rule goes beyond what the standard can express (distance constraints, segregation of hazardous products, site-specific logic). Custom WM code is heavy to maintain and often breaks on SAP upgrades. Before you code, make sure a storage section + bin type combination isn’t enough. Most of the time, the standard has you covered.
Conclusion: the bin type search, a detail that pays back its ROI fast
The storage bin type search isn’t glamorous. No new transaction, no shiny S/4HANA feature. But it’s the third tier that turns an approximate putaway into an industrial one. On the sites where I framed it correctly with the warehouse teams, we saw operator productivity climb noticeably, and manual corrections in LT12 drop significantly.
3 takeaways to remember:
- The third tier (T334P) is mandatory for a robust putaway. Without a bin type search, your site runs on gut feel.
- The SUT check active flag at the storage type level is the #1 trap. Check it before any other debug.
- Embedded EWM replaces WM in the long run per the official S/4HANA roadmap. The 3-tier logic survives, the implementation changes. Anticipate the migration in your WM design choices today.
Keep reading
SAP WM 2 Step Picking: Optimize your order-picking processes
2-step picking cascade in SAP WM 2-step picking SAP WM: the full cascade From group creation to the dispatched delivery Step 0: Group creation VL06P (deliveries) or LT41 (transfer requirements)...
Michael A.
SAP WM storage section search: tier 2 putaway (T334B)
In the WM scoping workshops with the key users, the Storage Section Search is often the one we deal with last. We quickly cover the Storage Type (the zone) and...
Michael A.
SAP WM storage type search: tier 1 putaway setup
On S/4HANA Supply Chain kickoffs, the end of SAP WM has become a recurring topic. And the discussion systematically drifts toward the putaway cascade. How does the Storage Type Search...
Michael A.
SAP EWM Master Data Integration: ERP Sync with CIF, ALE, DRF
Since the move to S/4HANA, the question "how do you synchronize data between SAP ERP and EWM" no longer has the same answer, and many projects still get it wrong...
Michael A.