SAP transaction codeObjectLX03ModuleWM_EWM

LX03 — Warehouse Stock Overview Report

LX03 is the classic WM warehouse stock overview report. It displays quants aggregated by storage type, storage section, storage bin, material or batch for a given warehouse number. It is read-only: no quantity can be changed from this screen. Fixing stock requires a transfer order, physical inventory posting, or a movement transaction elsewhere.

This page covers LX03, the classic Warehouse Management stock overview transaction used to inspect quant-level stock across storage types and bins. It focuses on why the report appears empty or mismatched against other stock views, and how to trace a discrepancy back to the underlying quant table or an unconfirmed transfer order.

Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,096 words

Purpose

LX03 is the warehouse stock overview report in classic Warehouse Management. It reads quant records and presents them aggregated by storage type, storage section, storage bin, material, batch or stock category for a chosen warehouse number. The structural fact that explains most confusion around it: LX03 is a display and analysis layer only. It has no update logic of its own. Consultants new to WM sometimes expect to correct a wrong bin quantity from this screen, or double-click a line expecting a change dialog. Nothing happens, because there is nothing to change here. The actual stock lives in the quant table, and it only moves through a transfer order, a posting change, or a physical inventory adjustment. LX03 exists to let someone see that stock, sliced different ways, before deciding what movement transaction to run against it.

When it is used

LX03 gets pulled up whenever someone needs a broader view than a single bin: preparing a cycle count, investigating a reported discrepancy between physical count and system stock, checking capacity utilization across a storage type before a putaway run, or supporting an audit that asks for stock by material across the whole warehouse. It sits alongside LS24 and LS26, which give narrower single-bin or single-storage-type views; a consultant reaches for LX03 when the question spans multiple bins or storage types at once rather than one specific location. It is a classic WM transaction. If the storage location in question is managed by an EWM-decentralized or embedded warehouse rather than classic WM, LX03 will show nothing useful, because the quant data lives in the EWM stack instead.

How to use it in practice

  • Enter the warehouse number on the selection screen
  • Restrict by storage type, storage section, or storage bin range as needed
  • Add material number, batch, stock category or special stock indicator if the question is material-specific rather than location-specific
  • Choose the aggregation and display variant that matches the question being asked (bin level versus storage type total)
  • Execute and review the list; double-click a line to drill into the underlying quant detail rather than trusting only the summary row
  • Navigate from the detail list to create a transfer order or trigger a follow-on movement if a correction is needed

Key data objects

  • LQUA - the quant table; the actual stock quantity per warehouse, storage type, bin, material and batch that LX03 aggregates and displays
  • LAGP - storage bin master data; bin coordinates, capacity, and blocking indicators referenced when the report shows bin-level detail
  • MLGN/MLGT - material warehouse-level and storage-type-level data; used to resolve unit of measure and storage-type-specific attributes shown in the list
  • LEIN - storage unit records, referenced when the warehouse is handling-unit or storage-unit managed and the report breaks stock down by storage unit

How to prove it in the data

To confirm what LX03 is showing, go to SE16 on LQUA and filter by warehouse number, storage type, and material. Compare the quantity field against the line LX03 displays for the same combination. If the report appears to be missing stock, check LAGP for the same bin to see whether a blocking indicator or empty-bin flag is set, and check whether the special stock indicator or stock category on the LX03 selection screen excludes quality inspection or blocked stock by default.

ECC vs S/4HANA

LX03 continues to function on S/4HANA for warehouses still run under classic WM. Nothing structural changes in the transaction itself. For warehouses migrated to embedded or decentralized EWM, the equivalent stock overview lives in a different report and Fiori app native to the EWM stack, and LX03 will not reflect that warehouse's stock at all. The first check on any S/4HANA system where LX03 looks wrong is whether the warehouse number in question is still classic WM or has already moved to EWM.

Common pitfalls and how to diagnose them

  • Empty result set: the warehouse number is not classic WM at all, or the selection screen has a default stock category or special stock indicator that excludes quality inspection, blocked, or consignment stock; check the selection screen fields before concluding stock is missing.
  • Totals do not match LS26 or a manual LQUA query: the mismatch is usually the aggregation level chosen, not a data error; a batch split can produce several quant lines that LX03 rolls up differently depending on the display variant, so drill into the detail rather than trusting the summary total.
  • Expectation of editing stock directly: LX03 has no update path; any attempt to correct a quantity from this screen goes nowhere, because the fix belongs in a transfer order, a posting change, or a physical inventory document, not in the report.
  • Bin shows a quantity that does not match a physical count: check for an open, unconfirmed transfer order reserving or moving that quantity before assuming the master data is wrong; the transfer requirement can hold stock in a transitional state that LX03 will still count.
  • Apparent authorization gaps: a user restricted to certain storage types or warehouse numbers by role will see a partial list and may report it as missing stock; confirm the authorization scope before escalating as a data problem.

Whose problem this is

This is a functional WM problem in almost every case. Basis involvement is limited to authorization object assignment when users report restricted visibility. ABAP involvement only comes up if a custom selection variant or downstream interface has been built on top of the report. A good handover states the warehouse number, storage type or bin range checked, the expected versus actual quant quantity, and whether any transfer order is open against the bin in question.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tcodes/lx03ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.