MLGN table — Material Master WM View at Warehouse Number Level
MLGN holds the classic Warehouse Management view of the material master at warehouse-number level, one row per material per warehouse number. It carries data that applies uniformly across every storage type in that warehouse, such as the warehouse-level deletion flag, maximum storage-unit quantities, and rounding quantities used in putaway and picking proposals. Storage-type-specific control sits in MLGT, not here.
This page covers MLGN, the SAP table that stores the warehouse-number-level Warehouse Management extension of the material master used in classic WM. It focuses on how MLGN differs from the storage-type-level MLGT, which fields are safe to trust, and the common misdiagnosis of confusing an absent warehouse-number extension with a missing storage-type extension.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,071 words
What it stores
One row in MLGN represents the Warehouse Management view of a single material for a single warehouse number, independent of any storage type inside that warehouse. It is created when a material is extended to a warehouse number for classic WM processing, either through the material master WM view maintenance or through mass extension tools. The row carries control data that is expected to be constant across all storage types within that warehouse number: a warehouse-level deletion flag, maximum quantity thresholds used when the system proposes a storage unit type during putaway, and rounding quantities that smooth transfer order quantity proposals during picking and putaway. It does not carry anything specific to a bin, a storage type, or a quant. Anything that varies by storage type, such as the putaway or removal strategy indicator, lives one level down in MLGT, which extends MLGN.
Key fields
- MATNR - material number, part of the key
- LGNUM - warehouse number, part of the key
- LVORM - deletion flag at the warehouse-number level; does not reflect deletion flags set at storage-type level in MLGT
- LHMG1 / LHME1 - maximum quantity and unit of measure for storage unit type 1, used in storage unit determination during putaway
- LHMG2 / LHME2 - maximum quantity and unit of measure for storage unit type 2, same purpose as the pair above for a second storage unit type
- RDMNG - rounding quantity applied when the system proposes quantities for putaway or picking transfer orders
How it joins the data model
- MLGN-LGNUM = T300-LGNUM, resolves the warehouse number to its configuration and controlling plant
- MLGN-MATNR + MLGN-LGNUM = MLGT-MATNR + MLGT-LGNUM, extends the warehouse-level view down to each storage type the material is assigned to
- MLGN-MATNR + MLGN-LGNUM = LQUA-MATNR + LQUA-LGNUM, links to the actual quants held for that material in that warehouse
- MLGN-MATNR + MLGN-LGNUM = LTAP-MATNR + LTAP-LGNUM, links to transfer order items created for that material, useful when tracing why a proposed unit quantity looks rounded
How to read it safely
Always restrict on MANDT and then on LGNUM before touching MATNR ranges; a warehouse number filter alone can still return every material ever extended to that warehouse, which for a mature production system is a large set. MATNR plus LGNUM together is the real selective key, so if the material number is known the read is cheap regardless of warehouse size. Do not attempt to filter on storage type against this table, since the storage type simply does not exist here; that filter belongs on MLGT. Treat blank numeric fields as unrestricted, not as zero or error.
How to prove it in the data
Symptom: a transfer order cannot be created for a material in a given warehouse, with an error referring to a missing warehouse view. Select MLGN on MATNR equal to the material and LGNUM equal to the warehouse number. If no row returns, the material has never been extended to that warehouse number for WM at all, and the fix is extending the WM view through material master maintenance, not touching storage type assignment in MLGT, which would come next and fail again for the same underlying reason.
ECC vs S/4HANA
MLGN remains active in S/4HANA for warehouse numbers still run under classic Warehouse Management; the table shape and key have not changed. It plays no role for warehouse numbers operated under embedded or decentralized EWM, since EWM maintains its own material data structures separate from this classic WM material master extension. There is no compatibility CDS view standing in front of MLGN in the way there is for some FI or SD tables; direct table access and the classic material master transactions remain the way to read and maintain it.
Common pitfalls
- Confusing MLGN with MLGT: a clean MLGN row proves the material is extended to the warehouse number, it says nothing about whether the material is assigned to the specific storage type the transfer order is trying to use.
- Treating a blank LVORM in MLGN as proof the material is not blocked; the deletion flag can be set independently at storage-type level in MLGT while the warehouse-level flag stays clear.
- Reading empty LHMG1/LHME1 or LHMG2/LHME2 as a configuration error; empty simply means no maximum storage unit quantity limit is enforced, which is a valid and common setup, not a defect.
- Assuming a missing MLGN row means the material master extension process is broadly broken, when it usually means one specific warehouse number was never selected during the extension transaction, often because the plant to warehouse number assignment was wrong at the time.
- Chasing odd transfer order quantities through movement types and strategy settings before checking RDMNG; a nonzero rounding quantity here explains lot-of-the-rounding-looking proposals long before any strategy customizing does.
- Assuming presence of an MLGN row implies the material also has active LQUA quant records; extension and stock existence are unrelated facts and a warehouse can hold an extended material with zero quants.
Whose problem this is
Material master governance owns the process of extending materials to a warehouse number, since that is the trigger that creates the MLGN row. The warehouse configuration or WM functional team owns the meaning of the rounding and storage-unit threshold fields once the row exists. A missing or incorrect row is a master data extension question first, a strategy or storage type question only after MLGN is confirmed present and correct.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/mlgnERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.