T320 table — Plant Storage Location to Warehouse Number Assignment

One row in T320 represents a single plant plus storage location combination and the warehouse number it is bound to. This is the pivot point of classic WM configuration: it is the record that tells the system whether a goods movement posted against a given plant and storage location must generate a transfer requirement and eventually a transfer order in a specific warehouse number. Without an entry, movements in that storage location are treated as ordinary inventory management postings with no WM relevance. With an entry, the storage location becomes WM-managed and every relevant movement type is expected to create WM follow-on documents. The table is maintained through customizing rather than direct master data transactions, and changes to it have structural consequences for open documents and existing stock.

T320 is client-dependent and small, typically a few dozen to a few hundred rows even in a large landscape, since it is a customizing table maintained by configuration rather than transaction volume. Restrict by WERKS and LGORT when the question is whether a specific storage location is WM-managed. Restrict by LGNUM when the question is which plants and storage locations feed a given warehouse number. A full table read is harmless here; the risk is not performance, it is reading it in isolation and concluding the assignment is currently effective without checking whether it was changed after stock was already posted.

Symptom: goods movements posted in plant 1000, storage location 0001 are not generating transfer orders even though WM is supposedly active for that location. Select T320 where WERKS = 1000 and LGORT = 0001. If no row exists, or LGNUM is blank, the storage location has never been assigned to a warehouse number and WM processing was never going to trigger, regardless of movement type configuration. If a row exists with a populated LGNUM, the problem lies elsewhere, most likely in movement type or storage type search strategy settings, not in the plant and storage location assignment.

T320 still exists in S/4HANA and still governs classic embedded Warehouse Management, which continues to be shipped for backward compatibility. The table structure has not changed. It plays no role in decentralized EWM, where warehouse number assignment and structure are defined and maintained inside EWM-specific customizing rather than through this table. Projects doing a WM to EWM migration typically decommission or freeze T320 assignments for the storage locations that move to EWM rather than reusing them.

Ownership sits with the logistics execution or WM configuration consultant, since this is an enterprise structure decision made once during warehouse setup and rarely touched afterward. Any proposed change needs sign-off from the MM consultant responsible for plant and storage location design, and coordination with whoever owns open transfer orders and current stock before the assignment is altered mid-stream.

T300 holds the warehouse number's general settings once T320 has pointed to it. T301 lists the storage types that live inside that warehouse number. LQUA and LAGP hold the actual quant and bin data for stock physically located there. LTAK and LTAP record the transfer requirements and transfer orders that only get created because a plant and storage location combination is assigned through T320 in the first place. Maintenance happens through the warehouse management customizing node, not through a stock movement transaction.