Comprehensive Technical Architecture

and Configuration Guide for SAP

S/4HANA Extended Warehouse
Management (EWM)
1. Executive Summary and Architectural Evolution
The digital transformation of supply chain logistics has necessitated a shift from rigid, linear
warehouse management systems to flexible, object-oriented architectures capable of
handling high-volume complexity. SAP S/4HANA Extended Warehouse Management (EWM)
represents the pinnacle of this evolution, offering a robust platform that operates either as an
embedded component within the S/4HANA Enterprise Management core or as a
decentralized instance on a dedicated stack. This report provides an exhaustive technical
analysis of the SAP S/4HANA EWM landscape, specifically engineered for solution architects,
technical consultants, and senior developers.

Unlike its predecessor, Logistics Execution Warehouse Management (LE-WM), which relied
on direct table updates and a simplified quant structure, S/4HANA EWM is built upon a
sophisticated framework of distinct layers: the Service Class Delivery (SCDL) layer for
document management, the Radio Frequency (RF) framework for mobile execution, and the
Logistics Inventory Management Engine (LIME) for stock persistence. Understanding these
layers requires a deep dive into the system’s data models—characterized by the pervasive
use of Globally Unique Identifiers (GUIDs)—and the extensive extensibility options provided
by Business Add-Ins (BAdIs).

This document serves as a definitive reference for the critical Transaction Codes (T-Codes),
Database Tables, and BAdIs that drive warehouse operations. It moves beyond simple
enumeration to provide architectural context, explaining the causal relationships between
data objects, the logic of transactional flows, and the strategic implementation of
enhancements to optimize Inbound, Outbound, Internal, and Reporting processes.

2. Foundational Architecture and Data Model

Concepts
To master SAP EWM, one must first appreciate the architectural divergence from legacy SAP
ERP modules. The system is designed to be deployment-agnostic, supporting both
embedded and decentralized scenarios. This requirement fundamentally dictates the data
model, particularly regarding Master Data identification and Transactional Data keys.

2.1 The Role of GUIDs and the /SCDL/ Namespace

In traditional SAP ERP (ECC), primary keys for documents were human-readable character
strings (e.g., VBELN as CHAR10). However, S/4HANA EWM utilizes 16-byte Raw Globally
Unique Identifiers (GUIDs) for almost all primary keys. This design choice enables the system
to consume documents from multiple upstream ERP systems (in a decentralized deployment)
without number range conflicts.
● Implication for Developers: You cannot simply query a table using a delivery number
string. You must first resolve the human-readable number to its GUID using mapping
tables or service classes.
● The Service Class Delivery (SCDL): Delivery processing is governed by the SCDL, a
framework that normalizes Inbound Delivery Notifications (IDN), Inbound Deliveries (ID),
Outbound Delivery Requests (ODR), and Outbound Delivery Orders (ODO) into a
consistent object model. This is why delivery tables are prefixed with /SCDL/ rather
than /SCWM/.

2.2 Master Data Distribution and Persistence

Master data in EWM is separated into global data (valid for all warehouses) and warehouse-
specific data. The integration logic depends heavily on the deployment option:
● Decentralized EWM: Master data (Products, Business Partners, Batch) flows from ERP
to EWM via the Core Interface (CIF) or Data Replication Framework (DRF).
● Embedded EWM: Master data is accessed directly from S/4HANA tables (MARA,
BUT000), but EWM-specific attributes are still persisted in EWM tables to maintain
architectural consistency.

Key Master Data Tables

The following tables form the backbone of the EWM master data model. Note the prevalence
of the /SAPAPO/ namespace, a vestige of EWM's origin within the SAP Supply Chain
Management (SCM) suite.

Table Name Description Technical Details &

Architectural Insight
 Primary Key: MATID
/SAPAPO/MATKEY Product Master Header
(GUID)

Key Fields: MATNR

(Product No).

Context: This is the central

anchor for product data. It
maps the ERP material
number (MATNR) to the
internal EWM MATID. All
subsequent inventory and
transaction tables
reference MATID, not
MATNR. 1

Key Fields: MATID,

/SAPAPO/MATMAP Product Mapping
EXT_MATNR, LOGSYS.

Context: Essential for

decentralized
environments. It maps the
internal GUID to the
external material number
and the logical system of
the sending ERP, handling
scenarios where different
ERPs send the same
material number for
different products. 1

Key Fields: MATID,

/SAPAPO/MATTXT Product Descriptions
LANGU.

Context: Stores material

descriptions in multiple
languages. Unlike MAKT in
ERP, this is linked via GUID.
1
 Primary Keys: LGNUM
/SCWM/LAGP Storage Bins
(Warehouse No), LGPLA
(Storage Bin).

Context: Defines the

physical coordinates of the
warehouse. Contains
critical attributes like
MAX_WEIGHT,
MAX_VOLUME, and
STOR_SECTION. This table
is the target for Putaway
strategies. 1

Key Fields: LGNUM,

/SCWM/LAGPS Bin Status
LGPLA.

Context: A dynamic
extension of /SCWM/LAGP.
It tracks the current state
of the bin, such as SKZUA
(Putaway Block), SKZUE
(Stock Removal Block), and
verification fields.
Separation of static (LAGP)
and dynamic (LAGPS) data
improves database locking
performance. 2

Context: While technically

/SCWM/PACKSPEC Packaging Specification
a complex object spanning
multiple tables (Header,
Content, Level), the
Packaging Specification is
the master data
determining how a product
is packed. It replaces the
classic "Packing
Instructions" and is vital for
automatic packing and
 Wave Management. 3

Key Fields: SCU_GUID.

/SCMB/TOENTITY Supply Chain Unit

Context: EWM does not

use "Plants." It uses Supply
Chain Units (SCUs). This
table defines the SCU
entity, which is then
assigned to a Warehouse
Number (LGNUM). It holds
timezone and address
data. 2

3. Inbound Logistics: Architecture and Execution

The inbound process in S/4HANA EWM is designed to handle high-volume complexity,
transforming external procurement or production signals into executable warehouse tasks.
The technical flow involves a transition from the S/4HANA ERP delivery object to the EWM
delivery object, necessitating a mapping logic between the legacy LIKP/LIPS structures and
the EWM /SCDL/ object model.

3.1 Inbound Transactional Framework

The execution of inbound logistics is governed by a sequence of transaction codes that
manipulate the delivery object through its lifecycle states—from notification to goods receipt
and final putaway.

Key Inbound Transaction Codes

T-Code Technical Object Function & Architectural

Context

Maintain Inbound
/SCWM/IDN Inbound Delivery
Delivery Notification: This
Notification
transaction manages the
persistent data received
from the ERP system (or
external vendor) before it
is converted into an active
 Inbound Delivery. It acts as
a staging layer where data
validation occurs. Ideally,
this document is transient,
but in error scenarios, this
T-Code is used for
troubleshooting. 3

Maintain Inbound
/SCWM/PRDI Inbound Delivery
Delivery: The central
command center for
inbound logistics. This
transaction allows access
to the /SCDL/ delivery
objects. Users perform
goods receipt, adjust
quantities, and trigger
warehouse task creation
here. It interacts directly
with the Post Processing
Framework (PPF) to trigger
subsequent actions like
printing or auto-putaway. 5

GR Preparation - External
/SCWM/GRPE GR Preparation
Procurement: Designed
for high-speed receiving,
this transaction streamlines
the goods receipt process
for purchase orders,
allowing for HU creation
and label printing directly
at the point of unloading
(e.g., Door). 3

GR Preparation -
/SCWM/GRPI GR Preparation
Production: The
counterpart to GRPE,
specifically architected to
handle the integration with
 Manufacturing Execution
Systems (MES) or PP-PI,
handling receipts from
production orders. It
supports the receipt of
HUs from the end of the
production line. 3

Unload: This transaction

/SCWM/UNLOAD Unloading
manages the status of the
Transportation Unit (TU)
and the delivery items. It
updates the "Unloading"
status in the delivery
header and item tables,
triggering timestamps that
are critical for yard
management metrics. 3

Putaway for Inbound

/SCWM/TODLV_I Warehouse Task Creation
Delivery: A focused
transaction that bypasses
the general task creation
screen to filter specifically
for inbound delivery items
requiring putaway
strategies. It allows the
manual override of system-
determined bins. 3

3.2 Inbound Data Model and Tables

The data persistence layer for inbound deliveries in EWM differs significantly from ERP. It
uses the Service Class Delivery (SCDL) layer, which separates header and item data into
distinct tables based on the document category.
● Inbound Delivery Notification (IDN): The precursor document.
● Inbound Delivery (ID): The working document.

Core Inbound Delivery Tables

The primary keys for these tables are typically 16-character GUIDs (DOCID and ITEMID). This
design supports the distributed nature of the system.
Table Name Description Key Fields & Joins

Primary Key: DOCID

/SCDL/DB_PROCH_I Inbound Delivery Header
(RAW16).

Usage: Stores the header-

level status, partner
information references,
and administrative data for
the inbound delivery.

Key Join: Joins to

/SCDL/DB_PROCI_I on
DOCID. 1

Primary Key: ITEMID

/SCDL/DB_PROCI_I Inbound Delivery Item
(RAW16).

Foreign Key: DOCID.

Usage: Contains product

(PRODUCTID), quantity
(QTY), batch (BATCHNO),
and weight/volume data at
the line item level. It is the
source for creating
Warehouse Requests (WR).

Insight: This table does

not contain the HU
information directly; it links
to HUs via the
/SCWM/HUREF table. 2

Primary Key: DOCID.

/SCDL/DB_REQH Inbound Delivery
Notification Header
Usage: Stores the header
data for the notification
document (IDN), which
 precedes the actual
Inbound Delivery. Useful
for debugging interface
failures from ERP. 1

Primary Key: ITEMID.

/SCDL/DB_REQI Inbound Delivery
Notification Item
Usage: Stores item data
for the IDN. Used for
validation against the
original purchase order
before the Inbound
Delivery is created. 1

Keys: DOCID, REF_DOCID,

/SCDL/DB_REFDOC Reference Documents
REF_DOCNO.

Usage: Critical
Integration Table. This
table maps the EWM GUIDs
(DOCID) back to the ERP
Purchase Order numbers
or ERP Inbound Delivery
numbers (VBELN). Without
this join, it is impossible to
trace EWM objects back to
S/4HANA core documents.
1

Keys: DOCID, ITEMID,

/SCDL/DB_STATUS Status Management
STATUS_TYPE.

Usage: Stores the dynamic

status of the delivery (e.g.,
DGR for Goods Receipt,
DUN for Unloading). Unlike
ERP where status is a
column in the header table,
EWM uses this vertical
table allowing for infinite
 status types without
schema changes. 8

3.3 Inbound Extension Framework (BADIs)

Customizing the inbound process often requires intercepting standard logic during the
determination of destination bins or during the validation of goods receipt.

Critical Inbound BADIs

● BAdI: Check Destination Storage Bin
○ Technical Name: /SCWM/IF_EX_CORE_PTS_VERIF (Method: VERIFY).
○ Enhancement Spot: /SCWM/ES_CORE_PTS.
○ Context: This BAdI is invoked during the verification of a destination bin, particularly
when a user manually changes the system-proposed bin during task confirmation on
the RF gun.
○ Real-World Scenario: In a chemical warehouse, an operator might try to put away a
pallet of "Oxidizers" into a bin meant for "Flammables" because the proposed bin is
full. Standard configuration might check the storage type, but this BAdI can inject
logic to check the neighboring bins for compatibility, effectively enforcing a
segregation of duties at the bin level during manual overrides. 9
● BAdI: Putaway Strategy (Core)
○ Technical Name: /SCWM/EX_CORE_PTS_STRATEGY.
○ Enhancement Spot: /SCWM/ES_CORE_PTS.
○ Context: While EWM offers robust configuration for putaway strategies (e.g., Near
Fixed Bin, Pallet Storage, Addition to Stock), complex business rules often exceed
standard configuration.
○ Real-World Scenario: A "Dock-Aware" putaway logic. Standard EWM minimizes
travel distance based on XYZ coordinates. However, this BAdI can be implemented to
consider the specific Dock Door where the goods were unloaded. If unloaded at
Door 1 (North Side), the logic prioritizes bins in the Northern sector of the
warehouse, even if bins in the South are theoretically "closer" by linear distance but
blocked by conveyor belts. 10
● BAdI: Inbound Delivery Goods Movement
○ Technical Name: /SCWM/EX_DLV_GM.
○ Method: CHECK_GR_TYPE.
○ Context: Triggered before the Goods Receipt posting is committed to the database.
○ Real-World Scenario: Compliance Checks. Before allowing a Goods Receipt for
pharmaceutical ingredients, the system calls an external Quality Management
System (QMS) via this BAdI to ensure the vendor's batch certificate is valid. If the
external check fails, the GR is blocked in EWM, preventing the inventory from
entering the books. 12
4. Outbound Logistics: Architecture and Execution
The outbound process is characterized by the transformation of an Outbound Delivery
Request (ODR) into an Outbound Delivery Order (ODO)—the executable "Warehouse
Request"—and finally into an Outbound Delivery (OD) for the goods issue posting. This three-
tier structure is unique to EWM and provides a buffer for planning.

4.1 Outbound Transactional Framework

Outbound T-Codes facilitate the complex orchestration of Wave Management, Picking,
Packing, Staging, and Loading.

Key Outbound Transaction Codes

T-Code Technical Object Function & Architectural

Context

Maintain Outbound
/SCWM/ODR Outbound Delivery Request
Delivery Request:
Displays the request
received from ERP. In many
standard flows, this is a
pass-through object, but in
complex scenarios (e.g.,
Order Reduction), it allows
for the adjustment of data
before the Warehouse
Request (ODO) is
generated. 3

Maintain Outbound
/SCWM/PRDO Outbound Delivery Order
Delivery Order: The
primary workspace for
outbound planners. This
transaction manages the
ODO, which is the
"Warehouse Request."
Warehouse Tasks for
 picking are generated
against the items in this
transaction. It is here that
Route Determination and
Wave Assignment typically
occur. 3

Maintain Outbound
/SCWM/FD Outbound Delivery
Delivery: Represents the
final legal document. The
Goods Issue (GI) is typically
posted against this
document. This transaction
manages the transition
from "Picked" to "Shipped"
and triggers the final
updates to S/4HANA
Finance. 3

Maintain Waves: Critical

/SCWM/WAVE Wave Management
for optimization. This
transaction groups multiple
ODO items into waves to
synchronize picking
activities with shipping
schedules. It allows for
manual release, blocking,
and simulation of waves. 4

Load: Manages the

/SCWM/LOAD Loading
physical loading of
Handling Units (HUs) onto
Transportation Units (TUs)
or vehicles. It updates the
status of the TU and
triggers the generation of
shipping documents (BOL,
Manifests). 5

Post Goods Issue:

/SCWM/SGI Goods Issue
 Executes the final
inventory consumption
logic. It reduces the stock
in the /SCWM/QUAN table
and triggers the interface
to update S/4HANA core
inventory ledgers
(MATDOC). 3

4.2 Outbound Data Model and Tables

The outbound data model mirrors the inbound structure but utilizes the _O suffix. A critical
distinction must be made between the Outbound Delivery Order (ODO) and the Outbound
Delivery (OD). The ODO is the planning object; the OD is the result object.

Core Outbound Delivery Tables

Table Name Description Key Fields & Joins

Primary Key: DOCID

/SCDL/DB_PROCH_O Outbound Delivery Order
(RAW16).
Header

Usage: Header data for

the ODO (Warehouse
Request). This is the
document against which
Picking Tasks are created.
Contains Shipping Point,
Route, and Incoterms. 2

Primary Key: ITEMID.

/SCDL/DB_PROCI_O Outbound Delivery Order
Item
Foreign Key: DOCID.

Usage: Item details for the

ODO. Contains the "Open
Quantity" for picking.

Join: Links to
/SCWM/ORDIM_O (Open
 Tasks) via QDOCID
(Qualified Document ID)
and QITEMID. This linkage
is vital for reporting on
"Planned vs. Actual"
picking status. 2

Primary Key: DOCID.

/SCDL/DB_DLVH_O Outbound Delivery
Header
Usage: Header data for
the Final Outbound
Delivery (FD). This record is
created/finalized when the
ODO is converted for
Goods Issue. 2

Primary Key: ITEMID.

/SCDL/DB_DLVI_O Outbound Delivery Item

Usage: Item details for the

Final OD. This table stores
the actual quantities being
goods issued. Any
differences (cuts/shorts)
during picking are reflected
here as reduced quantities
compared to the ODO. 2

Primary Key: WAVE

/SCWM/WAVEHDR Wave Header
(GUID), WAVE_NO.

Usage: Stores wave

attributes like release time,
cutoff time, and wave type.
Waves act as a grouping
meta-object for ODOs. 1

Keys: WAVE, ITEMID.

/SCWM/WAVEITM Wave Item

Usage: Links the Wave to

the Outbound Delivery
 Order Item
(/SCDL/DB_PROCI_O). This
table is the bridge between
Shipping Planning (Waves)
and Delivery Execution
(ODO). 1

4.3 Outbound Extension Framework (BADIs)

Outbound customization is essential for optimizing warehouse efficiency, focusing on Stock
Removal strategies and Warehouse Order Creation Rules (WOCR).

Critical Outbound BADIs

● BAdI: Stock Removal Strategy
○ Technical Name: /SCWM/EX_CORE_RMS_DETERMINE.
○ Enhancement Spot: /SCWM/ES_CORE_RMS.
○ Context: Triggered when the system searches for stock to fulfill a picking request. It
happens after the Storage Type Search Sequence but before the specific quant is
locked.
○ Real-World Scenario: Batch Determination with "Opened Box" Priority. A
standard FIFO strategy might pick a full pallet that arrived yesterday. However, the
business logic dictates that if a "broken" (opened) pallet exists in the picking area
with the same batch, it must be picked first to clear space, even if it arrived later.
This BAdI manipulates the CT_QMAT table (list of available quants) to bubble the
"opened" quant to the top of the list. 13
● BAdI: Warehouse Order Creation (General)
○ Technical Name: /SCWM/EX_WHO_CREATE.
○ Enhancement Spot: /SCWM/ES_WHO.
○ Context: As tasks are created, they are grouped into Warehouse Orders (WOs)
based on WOCRs. This BAdI allows for the complete takeover of this grouping logic.
○ Real-World Scenario: Volume-Based Cart Picking. Standard configuration limits
WOs by the number of items (e.g., max 10 items per WO). However, for a retailer
selling items of vastly different sizes (e.g., SD cards vs. Microwaves), item count is
irrelevant. This BAdI can implement logic to sum the volume of the tasks and close
the Warehouse Order exactly when the total volume matches the capacity of the
pick cart (e.g., 2 cubic meters), ensuring the picker never receives a list that
physically won't fit on their equipment. 16
● BAdI: Sort Warehouse Tasks
○ Technical Name: /SCWM/EX_WHO_SORT.
○ Context: Determines the sequence of tasks within a generated Warehouse Order.
○ Real-World Scenario: Stability-Based Picking. When picking mixed pallets, heavy
 items must be placed at the bottom. This BAdI overrides the standard "Path
Sequence" sorting to force tasks for heavy items (identified by weight in the Product
Master) to appear first in the WO, instructing the picker to pick the heavy items
before the fragile ones, reducing breakage during transport. 16

5. Warehouse Operations: Tasks, Orders, and Stock

At the heart of EWM execution lies the Warehouse Task (WT), which represents the atomic
unit of work (moving product A from Bin X to Bin Y). These tasks are grouped into Warehouse
Orders (WO) for execution by resources. This structure separates the "What" (WT) from the
"Who" (WO).

5.1 Warehouse Operations Transactional Framework

T-Code Technical Object Function & Architectural

Context

Create Product WT: Used

/SCWM/ADPROD Warehouse Task
for ad-hoc movements,
replenishment, or internal
scrapping. Unlike delivery-
based tasks, these are
generated directly by the
user. 3

Confirm Warehouse Task:

/SCWM/TO_CONF Task Confirmation
The desktop transaction
for confirming tasks. It
allows for difference
handling (zero pick, partial
pick) and exception code
entry. This is the "back-
office" equivalent of the RF
confirmation. 3

Warehouse Management
/SCWM/MON Warehouse Monitor
Monitor: The central
reporting and management
 tool. Unlike standard ALV
reports, the Monitor is a
hierarchical node-based
framework that allows
direct method execution
(e.g., cancelling tasks,
blocking bins, triggering
waves) from the display. It
is the "Control Tower" of
EWM. 4

Packing - General: The

/SCWM/PACK Packing Station
transaction for the packing
work center. It manages
the creation of shipping
HUs, repacking, and
recursive nesting of HUs. It
integrates with weighing
scales and label printers. 6

Create Physical
/SCWM/PI_CREATE Physical Inventory
Inventory Document:
Initiates the PI process. It
creates the PI document
header and locks the
bins/products for counting.
3

Analyze Differences: The

/SCWM/DIFF_ANALYZER Difference Analyzer
staging area for inventory
differences before they are
posted to the S/4HANA
core. This ensures that
operational errors (e.g.,
entering "10" instead of
"100") can be reviewed
and corrected by a
supervisor before
impacting the financial
ledger. 3
5.2 Stock and Task Data Model
The inventory model in EWM is based on the Quant, which is a unique combination of
Product, Batch, Stock Type, and Reference Document (if applicable) in a specific bin. This
differs from ERP IM (Inventory Management) which aggregates stock at the Storage Location
level.

Core Warehouse Task & Stock Tables

Table Name Description Key Fields & Joins

Primary Keys: TANUM

/SCWM/ORDIM_O Open Warehouse Tasks
(Task No), LGNUM.

Usage: Stores all active,

unconfirmed tasks.

Performance Insight:
High-volume read/write
operations occur here.
Custom code should
always query this table
using secondary indexes
(e.g., by Warehouse Order
or Source Bin) to prevent
database locks. 1

Primary Keys: TANUM,

/SCWM/ORDIM_C Confirmed Warehouse
LGNUM.
Tasks

Usage: Historical record of

all completed movements.
This table grows rapidly
and is a primary candidate
for data aging and
archiving (Archiving Object
WME_TO). 1

Primary Key: WHO

/SCWM/WHO Warehouse Order
(Warehouse Order
 Number).

Usage: Header for the

work package assigned to
a resource. Links multiple
tasks (/SCWM/ORDIM_O)
to a single executor.
Contains the "Started At"
and "Confirmed At"
timestamps for Labor
Management. 17

Keys: LGNUM, MATID,

/SCWM/AQUA Available Quantity
LGTYP, LGPLA.

Usage: Aggregated view of

available stock in a bin.
Used for quick availability
checks during task
creation. It avoids the need
to sum up individual
quants. 1

Primary Key: QID (Quant

/SCWM/QUAN Quant Attributes
ID).

Usage: Stores the detailed

attributes of the stock
(Batch, GR Date, SLED,
Stock Type). This links to
the physical stock tables
(LIME). It is the source of
truth for stock
characteristics. 1

Context: Maps the Quant

/SCWM/STOCK_IW01 Stock Key Mapping
GUID to standard inventory
attributes like Material,
Plant, and Storage
Location. Vital for
 reconciling EWM stock with
ERP MARD tables. 7

5.3 Handling Unit (HU) Data Model

Handling Units are crucial for tracking packaging. The EWM HU model is distinct from the ERP
HU model (VEKP/VEPO). In EWM, HUs are treated as physical objects that can be moved
(nested), stored, or shipped.

Table Name Description Key Fields & Joins

Primary Key: GUID_HU

/SCWM/HUHDR Handling Unit Header
(GUID).

Alternate Key: HUIDENT

(External HU ID - CHAR20).

Usage: Stores dimension,

weight, and packaging
material of the HU.
Contains the
TOP_HU_GUID to manage
nested HU structures (e.g.,
a box inside a pallet). 1

Keys: GUID_HU, DOCID.

/SCWM/HUREF Handling Unit Reference

Usage: Critical Linkage

Table. Connects the HU to
the Delivery Document
(/SCDL/DB_PROCH_*).
Without this table, you
cannot determine which
HU belongs to which
delivery. It resolves the
many-to-many relationship
between HUs and
Deliveries (Cross-Docking).
7
 Usage: Stores the history
/SCWM/GMHUIDENT GM HU Log
of HU IDs involved in goods
movements, essential for
traceability and regulatory
audits. 7

6. Radio Frequency (RF) Framework Architecture

The RF framework in S/4HANA EWM is built on a specific interaction model that decouples the
business logic from the presentation layer (ITS Mobile). It allows warehouse operators to
interact with the system via handheld devices. The architecture is "State Machine" based,
moving users through a sequence of Logical Transactions and Steps.

6.1 RF Tables and Configuration

The flow of screens on an RF gun is determined by configuration tables that map logical
steps to function modules and screens (Dynpros).

Table Name Description Function & Architectural

Context

Defines the high-level

/SCWM/TTRNS_CAT Logical Transactions
transactions available in
the RF menu (e.g.,
"Picking", "Putaway",
"System Guided"). It maps
the transaction code to the
start step. 2

Defines the individual steps

/SCWM/TSTEP_CAT RF Steps
within a logical transaction
(e.g., "Scan Source Bin",
"Scan Product", "Enter
Quantity"). Each step is
linked to a Function Module
(Logic) and a Screen
(Presentation). 2

Defines the hierarchy of

/SCWM/RFMENU RF Menu Structure
 the menu displayed to the
user after login. This table
allows for the
customization of menus
based on the user's
"Presentation Profile,"
enabling different menus
for Forklift Drivers vs.
Pickers. 18

Defines the screen profiles

/SCWM/TPRES_CAT Presentation Profiles
(e.g., 8x20 character mode
vs. graphical mode) for
different devices. This
allows the same business
logic to be rendered
differently on a vehicle-
mount terminal vs. a small
handheld scanner. 2

6.2 RF Extension Framework (BADIs)

RF customization is one of the most common requirements to improve usability or add
validation steps.
● BAdI: RF Framework Enhancements (Validation)
○ Technical Name: /SCWM/EX_RF_VI.
○ Enhancement Spot: /SCWM/ES_RF.
○ Context: Triggered during the PAI (Process After Input) of RF screens.
○ Real-World Scenario: GS1-128 Barcode Parsing. A standard RF screen might
expect a simple material scan. However, a vendor supplies labels with a complex
GS1-128 barcode containing Material, Batch, and Expiry Date. This BAdI can be
implemented to intercept the scan, parse the long string, and automatically populate
the Material, Batch, and Quantity fields on the screen, saving the user three separate
scans. 19
● BAdI: RF Framework Enhancements (Step Flow)
○ Technical Name: /SCWM/EX_RF_SS.
○ Context: Controls the transition between steps.
○ Real-World Scenario: Dynamic Screen Skipping. If a task is for a "Standard
Pallet," the system requires a confirmation of the Pallet Type. However, if the task is
for a "Wire Basket," the Pallet Type is implicit. This BAdI can check the HU type and
dynamically skip the "Confirm Pallet Type" screen for Wire Baskets, streamlining the
 flow for the operator.

7. Integration, Monitoring, and Post Processing

7.1 Post Processing Framework (PPF)
Unlike SAP ECC, which uses Output Determination (NAST), EWM uses the Post Processing
Framework (PPF) for all output and asynchronous actions (e.g., printing labels, sending ASNs,
triggering automatic warehouse tasks).
● Concept: PPF separates the "Condition" (Scheduling) from the "Execution"
(Processing).
● Key Tables:
○ PPFTTRIG: Stores the "Trigger" (The scheduled action).
○ PPFTEXEC: Stores the "Execution" status (Processed, Failed).
● Insight: When debugging printing issues or missing automatic tasks, one must check the
PPF logs (T-Code SPPFP) rather than NAST tables.

7.2 Warehouse Management Monitor

The Monitor (/SCWM/MON) is built on a hierarchical node structure.
● Extensibility: New nodes can be added to the monitor tree via configuration.
● BAdI: /SCWM/EX_MON_CUSTOM_SELECT allows developers to define custom selection
screens and logic for these new nodes, enabling the display of custom Z-tables directly
within the standard monitor framework. 20

8. Conclusion
SAP S/4HANA EWM represents a paradigm shift in warehouse technology. Its reliance on
object-oriented frameworks (SCDL), GUID-based data associations, and the state-machine-
based Radio Frequency framework provides unparalleled flexibility but demands a high
degree of technical rigor.

For the technical architect, success lies in understanding the separation of concerns:
1. SCDL manages the legal and logistical aspects of the delivery.
2. Warehouse Tasks manage the physical execution.
3. HUs manage the packaging layer.

By mastering the relationships between the tables detailed in this report—specifically the
linkage between /SCDL/ delivery objects and /SCWM/ execution objects—and utilizing the
strategic BAdIs for Putaway (/SCWM/ES_CORE_PTS) and Stock Removal
(/SCWM/ES_CORE_RMS), organizations can tailor the system to meet the most demanding
logistical requirements while maintaining a robust and scalable architecture.

引用的著作

1. SAP S4 HANA EWM IMPORTANT TABLES, 檢索日期：12 月 19, 2025，

[Link]
members/sap-s4-hana-ewm-important-tables/ba-p/13578494
2. SAP EWM Tables | 17 Most Important tables [2023] - HKR Trainings, 檢索日期：12 月 19,
2025， [Link]
3. SAP EWM Transactions - SAP Community, 檢索日期：12 月 19, 2025，
[Link]
members/sap-ewm-transactions/ba-p/14236503
4. SAP EWM Transaction Codes - List of SAP EWM T-Codes - SAP Online Tutorials, 檢
索日期：12 月 19, 2025， [Link]
transaction-codes/
5. T-codes for SAP TM/EWM - A Comprehensive Guide - NAV IT Consulting, 檢索日期：
12 月 19, 2025， [Link]
guide/
6. EWM Transaction Codes - SAP Help Portal, 檢索日期：12 月 19, 2025，
[Link]
7. List of EWM Tables in SAP S4 Hana - SAP Online Tutorials, 檢索日期：12 月 19, 2025，
[Link]
8. List of Important SAP EWM Tables | PDF - Scribd, 檢索日期：12 月 19, 2025，
[Link]
Tables
9. EWM BAdI Implementation Scenario-Bin Validation During Putaway (Manual
Change), 檢索日期：12 月 19, 2025， [Link]
management-blog-posts-by-members/ewm-badi-implementation-scenario-
bin-validation-during-putaway-manual/ba-p/14260272
10. Regarding to BADI /SCWM/EX_CORE_PTS_NBIN_NRM To allow mixed storage
doesn't do split during putaway - SAP Community, 檢索日期：12 月 19, 2025，
[Link]
badi-scwm-ex-core-pts-nbin-nrm-to-allow-mixed-storage-doesn-t/qaq-p/
14158730
11. Applying Putaway Rules - SAP Learning, 檢索日期：12 月 19, 2025，
[Link]
applying-putaway-rules
12. The Top 3 Enhancements in EWM Implementations - ITPFED, 檢索日期：12 月 19, 2025，
[Link]
13. Applying the Stock Removal Strategies - SAP Learning, 檢索日期：12 月 19, 2025，
[Link]
applying-the-stock-removal-strategies
14. SAP EWM BADI and FM's | PDF - Scribd, 檢索日期：12 月 19, 2025，
[Link]
15. Enhance quant determination in SAP EWM | [Link], 檢索日期：12 月 19,
2025， [Link]
16. Enhance Warehouse Order Creation in SAP EWM - [Link], 檢索日期：12 月
19, 2025， [Link]
17. Outbound Delivery and Warehouse Tasks table relations - SAP Community, 檢索日期：
12 月 19, 2025，
[Link]
delivery-and-warehouse-tasks-table-relations/qaq-p/11445927
18. EWM Components Common Expressions - SAP Help Portal, 檢索日期：12 月 19, 2025，
[Link]
19. Solved: SAP EWM RF Framework - SAP Community, 檢索日期：12 月 19, 2025，
[Link]
framework/qaq-p/12141176
20. EWM Monitor /SCWM/EX_MON_CUSTOM_SELECT BADI Part 1 - SAP Community,
檢索日期：12 月 19, 2025， [Link]
blog-posts-by-sap/ewm-monitor-scwm-ex-mon-custom-select-badi-part-1/ba-
p/14016144