MLGT table — Material WM Data at Storage Type Level

One row in MLGT represents the Warehouse Management master data for one material, in one warehouse number, in one storage type. Where MLGN carries the warehouse-number-wide WM settings for a material, MLGT drills one level further down to say how that material behaves inside a particular storage type: whether it has a fixed bin there, whether creation or putaway into that storage type is blocked, and which storage-type-specific quantities or units apply. A material stored in bulk storage and again in a fixed-bin picking area will have two MLGT rows, one per storage type, each carrying different control values even though the material and warehouse number are the same in both.

MANDT first, always. Then narrow by LGNUM before LGTYP, because a warehouse number can have dozens of storage types and the table is not small once materials are extended across several of them. Restricting on MATNR alone across all clients or all warehouse numbers is a common way to accidentally pull unrelated rows for the same material number used in different plants. LVORM should be checked explicitly rather than assumed blank; a set deletion flag changes the meaning of every other field in the row. Do not join to LQUA or LAGP as if MLGT guarantees a matching physical record: MLGT is master data, not a stock or bin status table.

Symptom: putaway keeps proposing a storage type the business says the material should never enter. Select MLGT with MANDT, MATNR and LGNUM fixed, and look at every LGTYP row returned. If a row exists for the unwanted storage type and LVORM is blank, the material master genuinely allows that storage type; the fix is in material master WM maintenance or in the putaway strategy configuration referenced through T301, not in the warehouse task itself.

MLGT belongs to classic Warehouse Management, which continues to exist on S/4HANA as a transitional option alongside embedded EWM. Where classic WM is still active, MLGT keeps its shape and role unchanged. On installations that have moved to embedded EWM, the equivalent material control data is held in the EWM product master and storage-type-specific settings rather than in MLGT, so the table stops being populated for materials managed under EWM even though it may still hold historical rows for materials never migrated.

Warehouse master data or logistics execution configuration owns the storage-type control values in MLGT, since they come from material master WM views maintained by the MM/WM data team. Questions about why a specific storage type is or is not permitted for a material sit with whoever owns putaway and storage type strategy configuration, not with basis or the interface team.

MLGN carries the warehouse-number-level counterpart of the same material data. T301 and T320 hold the storage type and warehouse number configuration that gives MLGT's values their meaning. LAGP and LQUA confirm what is physically true about a bin or a quant, as opposed to what the material master allows. MLGT rows are maintained through the WM views of the material master transactions rather than through warehouse task or transfer order transactions.