IT CanvassTalk to an advisor
SAP modules hub · LessonReviewed by Ravi M, SAP Trainer, 10 yrs · Updated · Published · SAP S/4HANA 2023 · all levels

SAP WM

SAP WM (Warehouse Management) manages stock at the detailed bin level within a warehouse, movements, put-away, picking, so you know not just how much stock exists but exactly where. (In S/4HANA, EWM is the strategic successor.)

Quick answer

SAP WM manages the inside of a warehouse: storage types, sections and bins, and the transfer orders that move stock between them for putaway, picking and stock transfers. It sits on top of MM inventory, so a goods movement in MM triggers the physical work in WM, and it integrates with SD deliveries and PP staging. EWM is its successor.

Key takeaways
  • Watch out: stock can be right in MM and unpickable, because nobody confirmed the transfer order.

What WM does

WM manages the internal layout of a warehouse: storage types, sections and bins, and the movements between them (put-away of received goods, picking for deliveries, stock transfers). It provides bin-level visibility and control beyond the storage-location level of basic inventory management.

The idea underneath it is one line: inventory management knows how much you have, and warehouse management knows where it is. Without WM, stock sits in a storage location and finding it is a human problem. With WM, every quantity sits in a numbered bin and the system can tell somebody exactly where to walk.

Key processes and objects

  • Warehouse Structure: storage types, sections, bins.
  • Transfer Orders: the instructions to move stock.
  • Put-away & Picking strategies.
  • Stock at bin level.
  • Physical inventory in the warehouse.

The structure is a hierarchy and it is worth holding in order: a warehouse number contains storage types (racking, bulk, picking area, goods receipt zone), which contain storage sections, which contain storage bins. A bin is the smallest addressable place.

The document that moves stock between bins is the transfer order. It has a source bin and a destination bin, and it is confirmed when the movement physically happened. The gap between created and confirmed is stock that is in motion, and it is where most warehouse discrepancies live.

The other object worth naming early is the quant: a quantity of one material in one bin with its own batch and stock category. A bin can hold several quants, and it is the quant rather than the bin that a transfer order moves. Getting this straight makes the bin stock screens readable, because they are lists of quants and not lists of materials.

Physical inventory in WM is also bin based rather than material based, which is what makes cycle counting practical: you count a bin, not a material across the whole site.

How it integrates

WM sits on top of MM inventory: an MM goods movement triggers WM transfer orders for the physical put-away/picking. It integrates with SD (picking for deliveries) and PP (staging materials). For new implementations, EWM (Extended Warehouse Management) is the strategic, more capable successor.

The link that trips people is the interim storage type. A goods receipt in MM posts stock into WM at an interim bin, not at its final home; the putaway transfer order moves it from there to the rack. So stock can be correct in MM and still unavailable to pick, because nobody confirmed the transfer order. Two systems, both right, and the pallet is standing on the dock. See goods receipt.

The other direction matters as much. A sales order leads to a delivery, and picking the delivery creates a transfer order that takes stock from a rack to a goods issue area. Post goods issue then reduces the inventory. So the same interim pattern appears at the outbound end: stock can be picked and staged, which means it is committed to a customer and still on your books until the goods issue is posted. Reading a stock figure without knowing what is staged is how a warehouse promises the same pallet twice.

Follow a pallet from dock to rack

An hour on a training system with WM active, and the interim-bin behaviour stops being abstract.

  1. Post a goods receipt against a purchase order for a WM-managed storage location.
  2. Look at the stock in MM. It is there and it counts as inventory.
  3. Look at the bin stock in WM. It is sitting in the goods receipt interim storage type, not in a rack.
  4. Create the putaway transfer order. Read the destination bin the putaway strategy chose.
  5. Stop before confirming, and look at the bin situation: quantity in transit, source not yet empty.
  6. Confirm the transfer order. Now the rack bin holds it and the interim bin is clear.

Step five is the whole lesson. Everything a warehouse argues about, from stock that exists but cannot be picked, counts that do not match, pickers sent to empty bins, is some version of that in-between state.

Putaway and removal strategies

The part of warehouse management that produces measurable savings is the strategies, because they decide where the system sends people.

Putaway answers where an arriving quantity should go. Next empty bin is the simplest. Fixed bin sends a material always to its own place, which suits fast movers. Addition to existing stock consolidates rather than scattering. Near picking bin keeps popular items close to where they are picked.

Stock removal answers which bin to take from. FIFO takes the oldest, which matters where stock ages. Shelf life expiration takes what expires soonest, which is not the same thing. Large or small quantity picks whole pallets for big orders and opens a case for small ones, so pickers are not breaking pallets unnecessarily. Fixed bin simply goes to the known place.

Each is configured per storage type, and the reason to understand them rather than accept defaults is walking distance. A warehouse where fast movers are spread across the racking because putaway used next empty bin costs its pickers hours a day, and none of that appears in any report. It shows up as needing more staff.

The design question to ask is which materials account for most of the picks. Usually a small proportion does, and putting those on a strategy that keeps them close is most of the available benefit for very little configuration.

Learning it

Learn WM by following its end-to-end process, its master data, its configuration (in SPRO), and its integration points with finance and neighbouring modules. Hands-on practice in a training system is essential.

Worth knowing where this sits: classic WM is in maintenance and EWM is the successor. Learning WM is still worthwhile because the concepts of bins, storage types, transfer orders and putaway and removal strategies carry directly across, and a great many live systems still run it.

Version note: in S/4HANA, classic WM is available under an extended maintenance arrangement rather than as the strategic option, and new implementations are expected to use EWM, which is now delivered embedded in the S/4HANA system rather than only as a separate one. So the useful stance is to learn the concepts here and expect to apply them in EWM, where the equivalents are the warehouse process type and the warehouse task.

Common pitfalls

  • Learning screens, not the end-to-end process.
  • Ignoring the finance integration that every logistics module has.
  • Skipping master-data setup that the process depends on.
  • Reading MM stock and assuming it is pickable. Check the bin, not the storage location.
  • Unconfirmed transfer orders. They are invisible until somebody walks to an empty bin.
  • Designing bins around the racking only. See MM, inventory management and the module map.

Two more. Treating a bin as a material's home. A bin holds quants, and several materials can share one unless you have configured otherwise. Counting by material rather than by bin. Physical inventory in WM is bin based, and trying to run it the way inventory management does it produces counts that cannot be reconciled.

Where this goes next

Bins and transfer orders are a day, and designing a warehouse whose strategies send people the shortest way is the part you do in the course.

Already working on SAP and stuck on a live ticket?Get an expert SAP developer on screen-share to finish your daily tasks with you. Deliver on time, protect your reputation and your job. Monthly support only, no task-wise plans.Task assigned · no idea where to startStill stuck · your job on the lineExpert joins your screenDelivered on timeExplore On Job Support