T001L table — Storage Location Master Table

Each row in T001L represents one storage location defined under one plant: a code such as '0001' with a text description, existing within the client and tied to a specific plant. This is the organizational structure level below plant used for inventory management, stores, and warehouse processes. Creating a row here does not create stock, does not activate warehouse management for that location, and does not guarantee any material is extended to it. It only registers that the combination of plant and storage location is a valid organizational unit that later transactions, master data extensions, and stock postings are allowed to reference. Consultants query this table almost exclusively as a lookup or validation table, not as a source of quantities or values.

T001L is small and fully client-dependent; always restrict on MANDT and normally on WERKS, since reading it plant-first mirrors how the data is actually organized and used downstream. There is no date or status field worth filtering on beyond LVORM. Because the table has only a handful of rows per plant, performance is never the issue; the issue is over-trusting what a row implies. Treat a read of T001L as answering exactly one question: does this plant/storage location combination exist and is it flagged for deletion. Any question about stock, valuation, or warehouse activity requires a join out to MARD, MBEW, or the movement tables.

Symptom: a goods receipt is rejected with the storage location not found for the plant. Select T001L on WERKS equal to the plant and LGORT equal to the value entered. No row returned confirms the storage location was never created for that plant, which is a customizing gap, not a transactional error. A row returned but with LVORM set confirms the location exists but is blocked for further use, which is a different fix entirely.

T001L is unchanged in S/4HANA and continues as a normal customizing table maintained through the standard enterprise structure configuration path. It was not affected by the MATDOC restructuring of inventory management, since that change touched stock quantity and movement history, not the storage location master itself. No compatibility view replacement applies here; reads and joins against T001L behave the same as in ECC.

Storage location creation and deletion sits with the MM enterprise structure or plant master team, usually the same group that owns plant and purchasing organization configuration. Questions about whether stock or open documents still reference a location before deactivation belong to the inventory management or warehouse team, since the answer depends on MARD, MSEG, or MATDOC, not on T001L alone.

T001W holds the plant that every T001L row belongs to. MARD carries the stock quantities per storage location, and MSEG or MATDOC carry the movement history that populates it. Storage locations are maintained through the standard plant and storage location configuration transactions in the enterprise structure IMG, while stock and movements against them are created through goods movement and inventory transactions rather than through any transaction that writes T001L directly.