LAGP table — Storage Bin Master Table in Classic WM
LAGP is the storage bin master table in classic Warehouse Management. Each row describes one physical or virtual bin, identified by warehouse number, storage type, and bin coordinate, carrying static attributes such as capacity limits and block indicators. It does not hold stock quantities or storage unit contents; those live in LQUA and LEIN respectively.
This page covers what LAGP stores in classic WM, how it joins to quants, storage units, and transfer order lines, and the recurring mistakes made when someone reads bin capacity or block fields as if they described current stock. It also covers where the table stands once a warehouse number moves to embedded EWM.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 994 words
What it stores
LAGP holds the master record for each storage bin defined in classic Warehouse Management. One row is one physical or virtual storage location, identified by warehouse number, storage type, and storage bin coordinate. It carries the static attributes of that bin: capacity limits, block indicators for putaway and removal, storage section, fire containment section, and bin type classification. It does not hold stock quantities; that is LQUA. It does not hold storage unit contents; that is LEIN. LAGP rows are created automatically when a storage type is generated with block storage bin creation, maintained one by one through bin master maintenance, or generated in bulk during warehouse setup or expansion.
Key fields
- MANDT - client
- LGNUM - warehouse number
- LGTYP - storage type
- LGPLA - storage bin coordinate, unique only within LGNUM plus LGTYP
- LGBER - storage section within the storage type
- LPMAX - maximum quantity used by the capacity check for the bin
- LPMIN - minimum quantity threshold used by the capacity check
- LTKZE - indicator blocking the bin for stock placement
- LTKZA - indicator blocking the bin for stock removal
- XLEER - indicator that the bin is currently empty
How it joins the data model
- LAGP-LGNUM = LQUA-LGNUM and LAGP-LGTYP = LQUA-LGTYP and LAGP-LGPLA = LQUA-LGPLA, to find quants physically sitting in the bin
- LAGP-LGNUM = LEIN-LGNUM and LAGP-LGTYP = LEIN-LGTYP and LAGP-LGPLA = LEIN-LGPLA, to find storage units placed in the bin
- LTAP-NLPLA = LAGP-LGPLA scoped by LGNUM and LGTYP, to identify the destination bin of a transfer order line
- LTAP-VLPLA = LAGP-LGPLA scoped by LGNUM and LGTYP, to identify the source bin of a transfer order line
- LAGP-LGTYP = T301-LGTYP, to pull the bin type classification and its control settings
How to read it safely
LAGP is client-dependent through MANDT and keyed by LGNUM, LGTYP, LGPLA. Row counts per warehouse number are moderate, from a few thousand to a few hundred thousand, so a full read restricted to warehouse number and storage type is usually fine, but never query without at least the warehouse number filter. Selectivity varies enormously by storage type: a random high rack area can have tens of thousands of bins while a staging or door area has a handful. Never select on LGPLA alone across a client, the same bin coordinate string can exist in more than one storage type and looks identical in a flat list. When hunting for blocked bins, filter directly on LTKZE and LTKZA rather than opening each bin in the maintenance transaction.
How to prove it in the data
To confirm a specific bin is blocked for putaway, select LAGP for the given LGNUM, LGTYP, LGPLA and check whether LTKZE carries a non-blank value. Cross check the same key against LQUA to see whether the bin currently holds stock. A full bin blocked for putaway is expected behaviour. An empty bin sitting blocked for putaway with no open reason usually means a manual block was set during an exception and never cleared.
ECC vs S/4HANA
On S/4HANA where a warehouse number still runs on classic WM rather than decentralized or embedded EWM, LAGP remains the live storage bin table with the same shape known from ECC. Once a warehouse number is migrated to embedded EWM, storage bin management moves to the EWM data model and LAGP simply stops being written for that warehouse number, though the table itself still exists in the system. There is no widely referenced compatibility view standing in front of LAGP, and its structure has not been renamed or restructured across releases.
Common pitfalls
- Reading LPMAX and LPMIN as if they describe current occupancy. They are static limits; actual fill level comes from LQUA and LEIN, and the capacity check only triggers when it is switched on at the storage type.
- Assuming a bin with no LQUA rows is unused. It may be logically blocked, reserved for a specific movement, or simply excluded from the active putaway strategy without being physically anything.
- Deleting or archiving LAGP rows while open transfer order lines in LTAP still reference the bin as source or destination. This produces orphaned bin references and breaks transfer order confirmation.
- Treating LGPLA as globally unique. It is only unique within the combination of warehouse number and storage type; the same coordinate string can legitimately appear in two different storage types.
- Changing LTKZE or LTKZA through direct table maintenance instead of the bin change transaction. This bypasses change documents and leaves no audit trail for why a bin got blocked.
- Assuming a bin existing in LAGP means the putaway strategy can actually reach it. Reachability depends on storage type search strategy and control settings elsewhere in configuration, not on the bin record by itself.
Whose problem this is
The warehouse operations or logistics execution consultant owns bin master data and any question raised against LAGP, because bin definition is tied directly to storage type strategy and to putaway and removal control. Basis or data management is involved only for volume and archiving decisions. The physical warehouse layout on the floor is the ground truth the table has to match, never the reverse.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/lagpERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.