T301 table — Storage Type Master Table (WM)
T301 is the classic Warehouse Management configuration table that defines a storage type within a warehouse number - the physical or organizational subdivision such as high rack storage, bulk area, or goods receipt area. It holds the storage type key and control indicators, not bins, quants, or descriptions, which live in companion and text tables.
This page covers T301, the config table behind storage type definitions in classic Warehouse Management. It explains what a row actually represents, the joins consultants write to LAGP, LQUA, LTAP and LEIN, and the recurring mistakes made when someone treats a config table like a transactional one.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 985 words
What it stores
One row represents one storage type defined within one warehouse number. A storage type is the organizational division of a physical warehouse - high rack area, bulk storage, fixed bin area, goods receipt zone - and every storage bin, quant, and transfer order line ultimately points back to one. T301 stores the storage type key together with the warehouse number it belongs to, plus the control indicators that govern how that storage type behaves during putaway and stock removal: whether capacity is checked, whether negative stock is tolerated, how it participates in placement and removal strategies. It is master configuration data, set up once when the warehouse is designed and touched rarely afterward, unlike LTAP or LQUA which accumulate rows continuously through daily operation.
Key fields
- MANDT - client
- LGNUM - warehouse number, foreign key to T300
- LGTYP - storage type key, the value referenced by every downstream WM table (LAGP, LQUA, LTAP, LEIN)
- LGBKZ - storage type indicator, a short code used as the linking key inside stock placement and stock removal strategy tables
- descriptive text for the storage type is not stored in T301 itself, it lives in the companion text table keyed by language; additional control flags for capacity check, negative stock allowance and mixed storage exist on the record but are configuration switches rather than fields consultants typically query directly
How it joins the data model
- T301-LGNUM = T300-LGNUM, storage type belongs to a warehouse number
- T301-LGTYP = LAGP-LGTYP, storage bins physically created inside that storage type
- T301-LGTYP = LQUA-LGTYP, quants currently sitting in bins of that storage type
- T301-LGTYP = LTAP-VLTYP or NLTYP, source or destination storage type on a transfer order item
- T301-LGTYP = LEIN-LGTYP, storage units assigned within that storage type
- T301-LGNUM = T320-LGNUM, plant and storage location assigned to the warehouse number
How to read it safely
Always restrict by MANDT and LGNUM first. The table is small - a warehouse rarely has more than a few dozen storage types configured - so a full scan for one warehouse number causes no performance concern. The risk is not performance, it is interpretation: nothing in T301 tells you how much stock, how many bins, or how much activity exists in a storage type. That information sits in LAGP and LQUA. Reading T301 answers 'does this storage type exist and how is it configured', never 'is this storage type busy'.
How to prove it in the data
Symptom: transfer order creation fails to find a target storage type for a material during putaway. Select T301 by LGNUM to list every storage type configured for that warehouse, then cross-check the candidate LGTYP against LAGP filtered on the same LGNUM and LGTYP. If the storage type exists in T301 but returns zero rows in LAGP, the storage type is defined in configuration but no bins were ever created in it - the putaway strategy is pointing at an empty shelf, not a missing configuration entry.
ECC vs S/4HANA
The table structure is unchanged in S/4HANA for warehouses still run on classic embedded Warehouse Management, since it is definitional configuration and there was no functional reason to restructure it. For warehouses migrated to Extended Warehouse Management, the storage type concept is represented in EWM's own configuration structures under its own warehouse number concept, and T301 is simply not read for those warehouses at all - it remains relevant only on the classic WM side built on T300.
Common pitfalls
- Assuming a storage type missing from T301 for one warehouse means it was deleted system-wide - the same LGTYP key can be active for one warehouse number and never configured for another, since the table is keyed by LGNUM plus LGTYP together.
- Confusing storage type (LGTYP) with storage bin (LGPLA) or storage section (LGBER) - T301 knows nothing about individual bins, that detail is in LAGP.
- Looking for the storage type description in T301 and concluding it is missing - the description sits in the separate text table, and forgetting the language key breaks the join silently, returning no rows instead of an error.
- Editing a control indicator on T301 directly during a support connection instead of routing it through customizing transport - this changes putaway or removal behavior for the entire warehouse without a change record, and is very hard to trace back later.
- Deactivating or deleting a storage type row while open transfer orders in LTAP or live quants in LQUA still reference that LGTYP - leaves orphaned movements that error out on confirmation.
- Treating row count in T301 as a proxy for warehouse activity - a three-storage-type warehouse can move more volume in a shift than a fifteen-storage-type one; the table describes structure, not throughput.
Whose problem this is
Configuration ownership sits with the WM or logistics execution consultant who designed the warehouse layout. Basis and security have no stake in this table's content. Any change to a storage type definition or its control indicators is a customizing change and should move through the normal transport and impact review, checked against active placement and removal strategies before activation.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t301ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.