The SAP WM → EWM Crosswalk

The ERP warehouse number in T300 stays active on every S/4HANA warehouse path — it is what a warehouse path is assigned onto, not an object EWM replaces. EWM then defines its own warehouse number (LGNUM is four characters here against classic WM's three) and maps it to the ERP number.

One classic bin master becomes a bin master plus per-activity-area sort records: the same bin appears once per activity in the sort table, so filter the activity you mean before counting bins. The EWM bin key is still semantic — client, warehouse number, bin.

One classic quant table becomes a three-layer model that does not tie out row for row: quantities hang on nodes of the LIME tree, quant attributes sit apart, and available quants carry the identity columns. Key stock-identity analytics off available quants — and see the quirks guide's LIME stock model section.

The classic header/item pair flattens to task rows, and the warehouse order becomes the new grouping object above them. Confirming a task moves it out of the open table into the confirmed one, so neither alone is the history — see the quirks guide's open/confirmed section. Cancellations land in the task log table rather than either half.

Classic transfer requirements become warehouse requests, modeled in the shared /SCDL layer. The request header carries no readable document-number column at all — readable numbers arrive through the reference-document table or the successor processing document.

Coexistence, not succession: the ERP delivery is distributed into EWM, which creates its own inbound delivery or outbound delivery order and points back at the originating document through the /SCDL reference table (source business system, reference document number, reference item number). Both documents exist at the same time, and a delivery analysis has to say which one it is counting.

Classic physical-inventory documents are succeeded by LIME-layer physical-inventory documents. The true document header table is outside both catalogs — this reference carries the log header, the items, and the count-table rows, which is where the counted quantities actually live.

A concept pairing, not a column-for-column match. Storage-unit management genuinely ends with classic LE-WM — it is out of scope for SAP Stock Room Management — and handling-unit management is the successor concept: SAP's own LE-WM migration function maps a classic storage-unit type onto an EWM packaging material and handling-unit type. An HU is packaging material plus contents, with its own header and items, so nothing about it lines up field for field with a storage-unit record.

The trap here is the key change, not the field list. MLGN keys material plus warehouse number; the EWM warehouse product keys the product GUID plus the supply-chain-unit GUID plus the entitled party, and carries no warehouse-number column at all. MLGT's per-storage-type grain maps to the storage-type table — the same key plus the storage type. SAP's own warehouse-product migration function maps the classic fields onto the EWM ones, which is what makes the pairing checkable.