Operations Guide | PUBLIC

SAP EWM Integration with SAP S/4HANA FPS1 | 2023-03-01

Business Process Monitoring Guide

for SAP® Extended Warehouse Management
 Table of Contents
1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 About this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Applicability, Goals, and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Business Process Monitoring Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Warehouse KPIs – SAP Fiori Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 SAP Smart Business Cockpit for Extended Warehouse
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 Inbound delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2 Outbound delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.3 Wave pick in outbound delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.4 In all areas of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Core Data Service (CDS) Views and APIs . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 SAP EarlyWatch Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Check Monitor for SAP EWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Master Data Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Master Data Setup in SAP S/4HANA with SAP EWM . . . . . . . . . . . . . . 16

4 Business Process Description – Inbound Process . . . . . . . . . . . . . . 17

4.1 Create Purchase Order in SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 19
4.2 Create Inbound Delivery in SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 25

2 / 143
 4.3 Create Inbound Delivery Notification in SAP EWM . . . . . . . . . . . . . . . . 26
4.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 28
4.4 Create Inbound Delivery in SAP EWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 34
4.5. Post-Goods Receipt into ROD (Received on Dock) Storage
Location in SAP EWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 37
4.6 Create and Print HU Warehouse Task (Move Pick HUs from
Storage Bin to Pack Work Center) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 40
4.7 Confirm HU Warehouse Task in the Deconsolidation Area . . . . . . . . . . 40
4.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Perform Repacking and Create New HU/Print HU Labels . . . . . . . . . 41
4.8.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.9 Close HU and Activate Product Warehouse Tasks . . . . . . . . . . . . . . . . . 42
4.9.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.10 RFUI: Confirm Product Warehouse Tasks at Final
Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.11 Posting Change (ROD > AFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.11.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.11.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.11.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 46

3 / 143
 5 Business Process Description for Outbound . . . . . . . . . . . . . . . . . . . 47
5.1 Sales Order Process in SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 50
5.2 Outbound Processing Document in SAP ERP . . . . . . . . . . . . . . . . . . . . . 52
5.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 56
5.3 Outbound Delivery Request (ODR) in SAP EWM . . . . . . . . . . . . . . . . . . 56
5.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 60
5.4 Outbound Delivery Order (ODO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.3 Business Process via SAP Fiori Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 Wave Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.2 Business Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 71
5.6 Wave Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 76
5.7 Creation of Warehouse Tasks for Warehouse Request/
Warehouse Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7.2 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.7.3 Business Process Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . 87
5.8 Confirmation of Warehouse Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.8.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.9 RF-Picking Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.9.1 Business Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4 / 143
 5.10 Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.10.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.10.2 Business Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.10.3 Business Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.11 Goods Issue Posting and Creation of Final Delivery . . . . . . . . . . . . . . . 97
5.11.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.12 Posting Goods Issue in ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.12.1 Business Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.12.2 Monitoring via SAP Fiori Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.13 RFC (Remote Function Call) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.14 Communication Between SAP EWM and Non-SAP Systems . . . . . . . 101

6 Generic Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.1 Interface Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.1.1 qRFC Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2 Housekeeping Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.2.1 Error-Handling Procedures for Batch Jobs . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.2 Job Restartability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.3 Archiving and Archiving Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.3.1 General Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.3.2 Reading Archive Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3.3 Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3.4 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.4 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.4.1 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.4.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.4.3 Transaction ST03N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.4.4 Transaction STAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.4.5 Transaction ST05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.4.6 Transaction ST12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8 Legal Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5 / 143
 1 Getting Started
1 Getting Started 1.1 ABOUT THIS DOCUMENT
This guide describes a methodology for the SAP Extended Warehouse
2 Introduction
Management (SAP EWM) application. It describes how to maintain and run
3 Master Data the systems optimally. It contains specific information for various tasks and
lists the tools that can be used to implement a monitoring concept mostly for
4 Business Process key objects in the solution area. This guide also provides multiple references
Description – to further documentation around SAP S/4HANA® solution documentations,
Inbound Process
which provide further insights.
5 Business Process
Description The focus is currently on SAP EWM integration with SAP S/4HANA. The
for Outbound integration monitoring between SAP EWM and the SAP Transportation
Management (SAP TM) applications with the classical LDAP as well as the
6 Generic Part
new advanced shipping and receiving is planned for a later release. The
7 Appendix same is relevant for dedicated material flow system (MFS) monitoring.

8 Legal Require- 1.2 CHANGE HISTORY

ments
Version Date Description

1.0 March 2023 Initial release

Important SAP Notes

Please consider the following notes regarding system implementation and
performance to make sure the operating system is up-to-date.

SAP Note Number Description

3218673 Release information and restrictions of Decentralized

SAP EWM on SAP S/4HANA 2022

218648 SAP S/4HANA 2022: Release information and

restrictions for SAP EWM on SAP S/4HANA

1423066 Performance optimization in SAP EWM

1914127 Performance optimization in SAP EWM MFS

3107746 Housekeeping KBA for SCM-EWM-WOP

3090337 Housekeeping KBA for SCM-EWM-DLP

6 / 143
 2 Introduction
1 Getting Started 2.1 APPLICABILITY, GOALS, AND REQUIREMENTS
This operations guide is intended to support the setup of a monitoring
2 Introduction
concept for SAP EWM applications. The concept aims to define procedures
3 Master Data for business process-oriented monitoring, error handling, and escalations
for embedded and decentralized SAP EWM core business processes. These
4 Business Process procedures intend to ensure a smooth and reliable flow of the core business
Description – processes so that business requirements are met.
Inbound Process

5 Business Process The guide gives orientation for defining suitable application-oriented monitoring
Description objects in order to detect any irregularities or deviations from an ideal busi-
for Outbound ness process flow or to detect error situations concerning a core business
process at an early stage.
6 Generic Part

7 Appendix This best practice contains the available monitoring possibilities for SAP EWM
applications based on two examples of business processes from the major
8 Legal Require- areas of business: in- and outbound processes. The chapter “Generic Part”
ments includes scenario-independent topics such as performance monitoring.

Note: Throughout the years, SAP products have undergone a variety of changes.
In the past, key performance indicators (KPIs) as well as interfaces have been
monitored via SAP Solution Manager with the BPMon add-on. Many KPIs have
been moved into SAP EWM in different areas and transactions of the system.
In the future, as the successor of SAP Solution Manager, SAP Cloud ALM will
include functionality like Job & Automation Monitoring as well as Business
Process Monitoring.

2.2 PREREQUISITES
The team that should determine the monitoring concept, where the KPIs are
located, and how they will be used comprise the following areas:
• Business department
• Solution support organization (Basis or application support)
• Implementation project team/functional experts

System Prerequisites
To monitor business processes running on an SAP EWM instance on
SAP S/4HANA, the SAP S/4HANA system must be release 1610 or later.
To have most functionalities mentioned in this document available, it is
best to have the latest version installed.

7 / 143
1 Getting Started For monitoring and cross-checking, functionality further mentioned in the
guide, it’s key to have warehouse processes set up. This might also require
2 Introduction
the setup of:
3 Master Data • SD: Order-to-cash process
– Sales order entry
4 Business Process – Delivery creation
Description – – Posting goods issue
Inbound Process
– Billing document creation
5 Business Process – Transfer to accounting
Description • MM: Purchase order process
for Outbound – Purchase order entry
– Logistics invoice verification
6 Generic Part
– Invoice document creation (ERS settlement)
7 Appendix – Transfer to accounting
• FI/CO: Finance and Controlling
8 Legal Require- – The processes listed above
ments – Country-specific legal requirements (such as tax calculation)

Duration and Timing

The best time to apply this guide is during the planning or implementation phase
of the SAP EWM application to have the monitoring ready as soon as the system
is live. As most functionality is given – creating the sub-nodes, masks, and
assignment – implementing the concept might take approximately a week.

Related Best-Practice Documents and Other Available Sources

There are several best-practice documents available in the Best Practices
Explorer > SAP S/4HANA > On Premise > SAP Best Practices for SAP S/4HANA
> Supply Chain > Warehousing, which are related to this document. Please also
refer to SAP Help, the SAP S/4HANA Operations Guide, especially the sub-
chapter on SAP Extended Warehouse Management and the already introduced
chapter, Important SAP Notes. Also become familiar with the Check Monitor
functionality, which was extended with SAP EWM content, and leverage the SAP
EarlyWatch® Alert service. For using SAP EarlyWatch Alert, get in touch with
the responsible SAP account or refer to Chapter 2.7 of this guide.

The monitoring, scheduling, and consistency procedures proposed for each

business process step are the core of this document. The monitoring proce-
dures help to ensure that the technical processes meet the requirements for
stability, performance, and completeness. These procedures cover monitoring
for the three areas:
• Errors
• Performance and throughput
• Processing progress and completeness.

8 / 143
1 Getting Started For each of the business process steps, the following information will
be available:
2 Introduction
1. A detailed functional description of the process step
3 Master Data 2. Monitoring activities for the process step
3. Description of error-handling procedures, restartability, and escalation
4 Business Process procedures
Description – 4. A monitoring object table listing each relevant monitoring object,
Inbound Process
showing the:
5 Business Process – Monitoring object
Description – Monitoring transaction or tool
for Outbound – Monitoring frequency
– Indicator or error
6 Generic Part
– Monitoring activity or error-handling procedure
7 Appendix – Responsible team.

8 Legal Require- General monitoring activities that are valid for all or most scenarios are
ments described in the chapter “Generic Part.” Recommendations for performance
monitoring can be found in this chapter. The performance of the most impor-
tant steps of the core business processes should be monitored on a regular
basis. The monitoring procedure for performance monitoring of all steps that
are executed on the SAP EWM system is generally the same. Therefore, only
specific performance monitoring recommendations on selected business
­process steps will be available.

2.3 BUSINESS PROCESS MONITORING PROCESS

For a successful and efficient business-process monitoring concept, a process
for the execution of the monitoring concept must be defined. This includes
definition of the roles involved, designation of role responsible for carrying out
each activity within the process, and determination of how the different roles
within the support organization will communicate. A business-process moni-
toring concept must be tightly integrated with the support organization. This
includes integration with both the incident/problem management and change
management processes. These processes have to be adjusted such that com-
munication and escalation procedures contained within these processes ade-
quately support the business-process monitoring concept. This includes the
final communication of open alert to SAP via SAP ONE Support Launchpad.
Wherever communication connected with business process monitoring happens
outside these support processes, separate communication and escalation
paths and procedures must be defined.

9 / 143
1 Getting Started The first part of this document focuses on business process monitoring. In
the Generic Part, the focus is on background processes, such as communication
2 Introduction
between systems, performance tracking, and general system performance.
3 Master Data For housekeeping jobs, please refer to the general SAP S/4HANA Operations
Guide. Also highly recommended is the enablement of logs together with the
4 Business Process housekeeping jobs mentioned in the guide. The logs can be enabled via easy
Description – access menu > EWM > Settings > Application log. The log objects and level
Inbound Process
may be adopted based on the requirements of the current project phase.
5 Business Process Please align with your implementation team.
Description
for Outbound In the next chapters, tools and KPIs provided as standard by SAP are
represented.
6 Generic Part

7 Appendix 2.4 WAREHOUSE KPIS – SAP FIORI® APPS

As of release 1909, the following warehouse KPIs are available in SAP Fiori
8 Legal Require- launchpad:
ments • Number of overdue outbound delivery order items without goods issue
by ship-to party
• Number of blocked outbound delivery order items by planned goods issue
time
• Number of outbound delivery order items without pick warehouse tasks
by planned goods issue time
• Number of outbound delivery order items without goods issue by planned
goods issue time
• Number of outbound delivery order items without goods issue by ship-to
party
• Number of outbound delivery order items by goods issue status
• Number of outbound delivery order items with goods issue by actual
goods issue time
• Number of outbound delivery order items with incomplete wave
assignments by planned goods issue time
• Number of confirmed warehouse orders by queue
• Number of open warehouse orders by queue
• Number of open pick warehouse tasks by activity area
• Number of open put-away warehouse tasks by activity area
• Number of open warehouse tasks by activity area
• Number of open warehouse tasks by overdue time in hour
• Number of open warehouse tasks by warehouse process category
• Number of open warehouse tasks by warehouse process type

10 / 143
1 Getting Started The screenshot below shows what the application looks like. It can be adjusted
according to different filters, and selections can be saved for users.
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

2.5 S
 AP SMART BUSINESS COCKPIT FOR
EXTENDED WAREHOUSE MANAGEMENT
The SAP Smart Business cockpit for extended warehouse management, based
on an SAP Fiori app called SAP Smart Business cockpit, provides you with an
overview of the most important KPIs for a warehouse shift supervisor. It allows
the warehouse shift supervisors to monitor the workload on their shifts for
outbound and inbound deliveries, to determine overdue deliveries or delivery
items in real time, and to monitor both the average goods issue and goods
receipt delay time.

For further information about SAP Smart Business for extended warehouse
management, refer to the Administration Guide for SAP Smart Business
Cockpits. To set up the SAP Smart Business cockpit, refer to this guide.
For thorough information on KPI modeling, refer to this guide.

11 / 143
1 Getting Started The following KPI dimensions are available for modelling KPIs and can
be found in SAP Fiori Apps Library:
2 Introduction

3 Master Data 2.5.1 Inbound delivery

• Number of inbound deliveries
4 Business Process • Number of inbound delivery items
Description – • Gross weight of inbound delivery items
Inbound Process
• Volume of inbound delivery items
5 Business Process • Outstanding unloading of inbound deliveries
Description • Outstanding goods receipt completion of inbound deliveries
for Outbound • Outstanding put-away completion of inbound delivery items
• Overdue arrival of inbound deliveries
6 Generic Part
• Average waiting time in yard
7 Appendix
2.5.2 Outbound delivery
8 Legal Require- • Number of outbound deliveries
ments • Number of outbound delivery items
• Volume of outbound delivery items
• Gross weight of outbound delivery items
• Overdue outbound delivery items
• Overdue outbound deliveries
• Average goods issue delay time

2.5.3 Wave pick in outbound delivery

• Number of wave pick items
• Weight of wave pick items
• Volume of wave pick items
• Number of deliveries for wave pick items
• Percentage of completion wave pick item tasks
• Overdue completion of wave pick tasks
• Items with incomplete creation of pick task

2.5.4 In all areas of operation

Task execution performance

12 / 143
1 Getting Started 2.6 CORE DATA SERVICE (CDS) VIEWS AND APIS
Another possibility is use of CDS views and APIs. These can be configured
2 Introduction
and used according to the business requirements.
3 Master Data
For CDS views: See this step-by-step guide with the example of outbound
4 Business Process deliveries. The corresponding CDS views can be found in the Outbound Delivery
Description – Order CDS Query for SAP Smart Business in SAP S/4HANA Cloud Guide.
Inbound Process

5 Business Process As the focus in system landscapes is shifting towards cloud capabilities, since
Description release 2021 FPS2, SAP provides various APIs to read, create, update, and
for Outbound delete (CRUD-Operations). As the current stack of APIs is growing with each
release, please refer to SAP Business Accelerator Hub.
6 Generic Part

7 Appendix After searching for warehouse APIs in SAP Business Accelerator Hub, the
following APIs show up:
8 Legal Require-
ments

2.7 SAP EARLYWATCH ALERT

Starting in 2020, the SAP EarlyWatch Alert service was extended with func-
tionality to track technical errors in SAP EWM. To leverage the functionalities
of SAP EarlyWatch Alert and learn how to set it up, please refer to the blog
post: SAP EarlyWatch Alert Workspace – gain an overview on your system
landscape health.

13 / 143
1 Getting Started The first prerequisite to use SAP EarlyWatch Alert for SAP EWM is an
on-premise or private cloud system such as SAP ERP powered by SAP HANA®
2 Introduction
or SAP S/4HANA. The second prerequisite is to enable data collection in
3 Master Data one of three ways:
• Via SAP Solution Manager
4 Business Process • Via direct transfer (SAP Note 207223)
Description – • In a private cloud via the cloud provider and a support user in SAP Early Watch
Inbound Process
Alert or SAP ONE Support Launchpad with the necessary authorization
5 Business Process (See “Service Reports & Feedback” for your respective customer number)
Description
for Outbound For the updated list and more information, please refer to the blog post:
Introduction of application specific Extended Warehouse Management
6 Generic Part
Checks in SAP EarlyWatch Alert. This blog will be updated as soon as
7 Appendix new functionality is available.

8 Legal Require- The below checks are included in the SAP EarlyWatch Alert and further
ments improvements can be expected:
• LIME tables inconsistency checks
• System parameters check
• Customizing checks for capacity updates (performance)
• Failed and unprocessed queues
• Failed and unprocessed PPF actions
• Update termination handling
• Recommendations on latest support-packages for SAP EWM
• Missing important SAP Notes
• Saved queues in SMQ3
• Recommended housekeeping jobs not set up
• Status of archiving
• Missing SAP Notes for SAP EWM correction
• Overdue outbound deliveries (created more than one year ago)
• Overdue warehouse tasks (created more than one year ago)
• SAP EWM check monitor statistics
• Flexible loading in SAP EWM
• Missing side-effect solving SAP Notes in SAP EWM
• Mix usage of different kinds of units of measure
• Tiny leftover quantities (<0,001) on storage bins

2.8 CHECK MONITOR FOR SAP EWM

To correct inconsistencies, we recommend leveraging the functionality of the
check monitor for SAP EWM as explained in the blog post: Check Monitor –
Check and Correct data inconsistencies in SAP EWM, as well as SAP Note
3058435 and the blog post: Overview of the SAP EarlyWatch Alert Check
Monitor. Another source of information for setting up the SAP EarlyWatch
Alert check monitor functionality: Check Monitor in the Support Wiki.
14 / 143
 3 Master Data Distribution
1 Getting Started With SAP S/4HANA, the distribution of master data from the core instance to
the SAP EWM application, embedded or decentralized, was changed from CIF
2 Introduction
to intermediate documents (IDocs). CIF is still used for packaging instructions.
3 Master Data
SAP ERP on SAP S/4HANA Decentralized SAP EWM on
4 Business Process
SAP S/4HANA
Description –
Inbound Process
Product (material) Product (material)
IDOC (ALE)
5 Business Process
Description

ALE distribution model

for Outbound
Batch Batch
IDOC (ALE)
6 Generic Part

7 Appendix Batch classification

(Class 22/23) IDOC (ALE)
Batch classification
(Class 22/23)
8 Legal Require-
ments Business Customer/ Customer/ Business
CVI CVI
partner vendor IDOC (ALE) vendor partner

SCM packaging
Packaging instruction
CIF

CIF (qRFC) instruction

CVI = Customer vendor integration

Material and business partner also possible via Web service

The IDoc transfer includes:

• Materials
• Customers
• Vendors and carriers
• Addresses
• Batches
• Class system: Characteristics master
• Class system: Classes master
• Class system: Classification master

Regarding distribution of packaging specifications, please refer to note

2260234 – Packing instruction/specification distribution from SAP ERP
application to SAP EWM.

15 / 143
1 Getting Started 3.1 MASTER DATA SETUP IN SAP S/4HANA WITH SAP EWM
While embedded SAP EWM makes use of the integrated scenario such that
2 Introduction
the application is accessing the same tables as SAP ERP, no further steps are
3 Master Data necessary despite extending master data with possible customer enhance-
ments. For more information, refer to the following: SAP Fiori app custom field
4 Business Process and logic. Blog post: “SAP EWM Product Master – Field Enhancement using
Description – Custom Fields and Logic App” with Explanations.
Inbound Process

5 Business Process To configure the master data distribution within an SAP S/4HANA landscape,
Description please refer to Chapter 6 of the Integration How-to-Guide, which contains a
for Outbound step-by-step guide: Integration of SAP ERP or SAP S/4HANA with decentralized
SAP EWM in SAP S/4HANA guide.
6 Generic Part

7 Appendix Further advice on setting up master data distribution can be found in the
SAP Help Portal site.
8 Legal Require-
ments As the CIF integration is still viable for packaging specifications. The following
chapters will explain how master data distribution works with SAP EWM 9.x
as well as for packaging specifications in SAP S/4HANA. Be aware that there’s
also a new functionality called Unified Package Builder (UBP), an API between
SAP S/4HANA, SAP Extended Warehouse Management, and SAP Transportation
Management. This UBP will consolidate and decide which system will be in
the lead. For more information, visit the Unified Package Builder.

16 / 143
 4 B
 usiness Process Description –
Inbound Process
1 Getting Started The inbound process is an essential part of the supply chain. This process
includes the steps after the creation of the purchase order: notification from
2 Introduction
the vendor, inbound delivery documents, execution of internal warehouse
3 Master Data tasks belonging to the put-away process, and goods receipt posting of the
ordered goods.
4 Business Process
Description – The inbound process usually begins in SAP ERP, when either an inbound
Inbound Process
delivery is created from a purchase order or an advanced shipping notification
5 Business Process (ASN) is received directly from the vendor via EDI interface and converted
Description into an inbound delivery document.
for Outbound

6 Generic Part SAP ERP SAP EWM

7 Appendix
Purchase order

8 Legal Require-
ments
[Inbound delivery
Inbound delivery
Replication notification]

Inbound delivery
order

Inbound delivery Goods receipt

Confirmation

Create put-away
warehouse task

Confirm put-away
Inbound delivery
Closing indicator warehouse task

17 / 143
1 Getting Started 4.1 CREATE PURCHASE ORDER IN SAP ERP
4.1.1 Description
2 Introduction
The purchase order is the central document to procure materials from
3 Master Data either external sources (e.g., external vendors) or from other plants
(e.g., stock transfer of materials).
4 Business Process
Description – Relevant transactions:
Inbound Process
• ME21N (create purchase order)
5 Business Process • ME22N (change purchase order)
Description • ME23N (display purchase order)
for Outbound • ME28 (mass creation of purchase orders)

6 Generic Part
Relevant SAP Fiori app:
7 Appendix • Create purchase order
• Manage purchase orders (version 2)
8 Legal Require- • Procurement overview page
ments • Monitor purchase order items

4.1.2 Business Process Monitoring

Purchase orders can be displayed via transaction code ME23N. Here, it is also
possible to check the current delivery status of the purchase order displaying
content in the tab “Status.”

18 / 143
1 Getting Started 4.1.3 Business Process Monitoring via SAP Fiori Apps
In parallel with the well-known transaction ME23N with status management,
2 Introduction
the SAP Fiori app Manage Purchase Orders is available. It shows the user
3 Master Data if there are overdue items, and the status details can be checked by clicking
on the specific line item.
4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Status Overview for a Single Purchase Order:

19 / 143
1 Getting Started The following screenshot shows the SAP Fiori app Procurement Overview.
This application contains KPIs such as supplier performance and allows
2 Introduction
users to jump directly into purchase orders:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

On a more detailed level, the Monitor PO Items Application is available where

additional information on purchase order items can be found. It’s also possible
to have specific selections according to predefined settings and filters.

20 / 143
1 Getting Started 4.2 CREATE INBOUND DELIVERY IN SAP ERP
4.2.1 Description
2 Introduction
An inbound delivery is created in SAP ERP either manually or automatically
3 Master Data (through a planned background job). It can be created with reference to purchase
orders, stock transport orders, customer returns, or scheduling agreements.
4 Business Process Another possibility is the automatic generation of inbound deliveries via ASNs
Description – received from non-SAP external systems, which are then converted into inbound
Inbound Process
deliveries via EDI processing. Once an inbound delivery is created and saved
5 Business Process in SAP ERP, the delivery-document data should be transferred to SAP EWM
Description via the standard qRFC interface. This data distribution can be executed either
for Outbound automatically (right after creation of the delivery in SAP ERP, manually, or
through planned background jobs in SAP ERP). If data distribution is processed
6 Generic Part
manually or through background jobs, the inbound deliveries that should
7 Appendix be distributed are processed via transaction VL06i.

8 Legal Require- Relevant transactions:

ments • VL31N (create inbound delivery)
• VL32N (change inbound delivery)
• VL33N (display inbound delivery)
• VL06i (inbound delivery monitor)
• VL60 (inbound delivery processing)

Relevant SAP Fiori apps:

Create inbound delivery
Change inbound delivery
Manage purchase orders (version 2)

4.2.2 Business Process Monitoring

The following transaction codes can be used for monitoring of inbound
­deliveries in SAP ERP:
• VL33N (display inbound delivery)
• VL06i (inbound delivery monitor)
• VL60 (inbound delivery processing)

Via transaction code VL33N, it is possible to check the current status of different
activities related to inbound delivery in SAP ERP, such as “Goods Movements.”
It is possible to check either the current overall status or the status of each single
item of the delivery.

21 / 143
1 Getting Started Four different statuses are possible for those activities:
• Blank: Not relevant
2 Introduction
• A: Not yet processed
3 Master Data • B: Partially processed
• C: Completely processed
4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

The following screenshot shows transaction code VL06I. This transaction

enables identifying and displaying inbound deliveries, based on predetermined
criteria, such as “delivery date.”

22 / 143
1 Getting Started After selecting “List Inbound Deliveries,” parameters for the selection can
be entered and the search executed.
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Example Output:

23 / 143
1 Getting Started Transaction code VL60 enables identifying and checking inbound deliveries
by “Vendor” and/or “External Delivery Number”:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

24 / 143
1 Getting Started 4.2.3 Business Process Monitoring via SAP Fiori Apps
SAP Fiori apps are available to create and monitor the status management
2 Introduction
of purchase orders and their corresponding Inbound deliveries:
3 Master Data • Create inbound delivery
• Monitor purchase order items
4 Business Process
Description – The SAP Fiori app Create Inbound Delivery enables users to create inbound
Inbound Process
deliveries to purchase orders as well as creating corresponding handling units
5 Business Process to pack the goods. The advanced shipping notification is defined and delivery
Description dates can be set.
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

In the application Monitor Corresponding Purchase Orders Items, it’s possible

to check the current status for purchase orders and corresponding items:

25 / 143
1 Getting Started 4.3 CREATE INBOUND DELIVERY NOTIFICATION IN SAP EWM
Note that this process is relevant only for SAP Extended Warehouse Manage-
2 Introduction
ment as a decentralized deployment. In an embedded deployment, the inbound
3 Master Data delivery will be directly created without an inbound delivery notification (IDN).

4 Business Process 4.3.1 Description

Description – During inbound-delivery data transfer from SAP ERP into the SAP EWM appli­
Inbound Process
cation, an IDN is generated in SAP EWM. The IDN contains all the relevant
5 Business Process logistics data in the inbound delivery process, which is transferred from a
Description reference document in SAP ERP (for example, inbound delivery, purchase
for Outbound order). The IDN is not used for processing within SAP EWM and does not
have an SAP EWM–specific document number.
6 Generic Part

7 Appendix Relevant transaction:

/SCWM/IDN (maintain inbound delivery notification)
8 Legal Require-
ments Relevant SAP Fiori transaction:
Inbound delivery notification (/SCWM/IDN)

4.3.2 Business Process Monitoring

Selection of Active Inbound Delivery Notification
The inbound delivery notification can be selected via transaction code
/SCWM/IDN (maintain inbound delivery notification), based on an SAP ERP
document number (if available). Alternatively, “Advanced Search” can be
used to identify the desired delivery:

26 / 143
1 Getting Started Below you will find an overview of the different selection options available
when using advanced search.
2 Introduction

3 Master Data Advanced search (search criteria 1):

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Advanced search (search criteria 2):

27 / 143
1 Getting Started Advanced search (search criteria 3):

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Selection of Inactive Inbound Delivery Notification

If no “active” IDN can be selected, the document can still be inactive. The
reason for an inactive IDN could be an unsuccessful check or missing data
for activation, such as a missing partner role; missing master data (batches,
products); and so on. Search criteria “DOCNO_IDN_IN” should be set in the
field “Find” for searching for an inactive IDN:

4.3.3 Business Process Monitoring via SAP Fiori Apps

Currently it is not possible to monitor IDNs via SAP Fiori app.

28 / 143
1 Getting Started 4.4 CREATE INBOUND DELIVERY IN SAP EWM
4.4.1 Description
2 Introduction

3 Master Data Subsequently, a second document in SAP EWM is created from the IDN:
the inbound delivery (ID). This step is performed via PPF action /SCDL/
4 Business Process IDR_TRANSFER, which is usually triggered directly after saving the IDN.
Description – This post-processing (PPF) action can be displayed in transactions
Inbound Process
/SCWM/PRDI and SPPFP.
5 Business Process
Description The following screenshot shows an extract of the PPF setup transaction
for Outbound SPPFCADM. Here, standard information about all PPF actions is given:

6 Generic Part

7 Appendix

8 Legal Require-
ments

The inbound delivery (ID) document has a document number assigned

in SAP EWM. The ID has the same basic structure as the IDN and contains
additional fields and information, relevant for triggering and monitoring
of the complete SAP EWM inbound process. The ID is used as a working
object in the inbound delivery process when executing the following actions:
• Registering the delivery in the yard
• Unloading the delivery
• Cancelling the “unloading of the delivery“
• Placing the delivery into stock (put-away)
• Cancelling the “delivery put-away“
• Adjusting the delivery quantity to the quantity posted in the goods receipt
(in case of over- or under-delivery)
• Posting a goods movement
• Cancelling a goods movement

29 / 143
1 Getting Started Optional Step: Based on customizing settings, handling units (HUs) are
created automatically in SAP EWM for HU-managed products that have been
2 Introduction
defined in SAP ERP. In the same way, batches are also created automatically
3 Master Data for batch-managed products defined in SAP ERP, according to customized
settings.
4 Business Process
Description – Relevant transaction:
Inbound Process
/SCWM/PRDI (maintain inbound delivery)
5 Business Process
Description Relevant SAP Fiori apps:
for Outbound • Create inbound delivery
• Change inbound delivery
6 Generic Part

7 Appendix 4.4.2 Business Process Monitoring

Via user interface transaction
8 Legal Require- Inbound deliveries (IDs) can be selected and checked via transaction code
ments /SCWM/PRDI (maintain inbound delivery). The following search criteria can
be set to identify IDs:
• SAP EWM inbound delivery
• Advanced shipping notification
• SAP ERP document (LE delivery)
• Purchase order
• Production order

The following screenshot shows the selection options within /SCWM/PRDI:

30 / 143
1 Getting Started If it is not possible to select any ID, even via “Advanced Search,” the following
actions should be considered:
2 Introduction
1. Search first for inactive IDN. (It is possible that an IDN could not be activated
3 Master Data because of missing data like batch number.)
2. Check the qRFC-Monitors SMQ1 (outbound queue) and SMQ2 (inbound
4 Business Process queue) for stuck queues. The qRFC inbound queue should be checked first
Description – via transaction code SMQ2.
Inbound Process

5 Business Process The queue name will appear as follows:

Description Example queue: DLVQKVCLNT1100180001542
for Outbound DLV: delivery
QKVCLNT110: related SAP ERP system and client
6 Generic Part
180001542: SAP ERP document number
7 Appendix
The following screenshot shows transaction SMQ2:
8 Legal Require-
ments

31 / 143
1 Getting Started For further analysis, it is possible to double-click on the desired queue. The
system skips to another screen, where further information related to the queue
2 Introduction
is displayed:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound Another double-click on the queue name provides more detailed information:

6 Generic Part

7 Appendix

8 Legal Require-
ments

Double-clicking on the field “Status Text” (application log) enables skipping

into the transaction SLG1 for a detailed application error analysis.

If the search in the SMQ2 was not successful, the outbound queue in
SAP ERP (SMQ1) for stuck queues should be checked as well. Analysis
should be performed analogous to the analysis in SMQ2:

32 / 143
1 Getting Started Via Warehouse Monitor
The central transaction for monitoring of inbound deliveries is transaction
2 Introduction
/SCWM/MON (warehouse monitor) under the following node: Inbound >
3 Master Data Documents > Inbound Delivery.

4 Business Process A new screen will be displayed when double-clicking on the node “Inbound
Description – Delivery.” Here, various specific criteria to support searching for the desired
Inbound Process
inbound delivery you can enter:
5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

After entering the selection criteria, the corresponding documents are selected.
It is possible to jump into transaction /SCWM/PRDI directly and display the
desired document just by clicking on the corresponding “Document” field
available for each document.

33 / 143
1 Getting Started 4.4.3 Business Process Monitoring via SAP Fiori Apps
Several CDS views are available related to inbound deliveries. One is
2 Introduction
“Inbound Delivery Item – Query.” Using these CDS views, the following
3 Master Data KPIs can be extracted:
• How many inbound delivery items are there in my warehouse?
4 Business Process • How many products are there for my inbound delivery items?
Description – • How many blocked inbound delivery items are there?
Inbound Process
• What are the warehouse process types of my inbound delivery items?
5 Business Process • What is the goods receipt status of my inbound delivery items?
Description • What is the average goods receipt time of my inbound delivery items?
for Outbound
Other than that, as already explained in Chapter 4.2.3, inbound deliveries
6 Generic Part
can be tracked and created with the application Create Inbound Deliveries.
7 Appendix

8 Legal Require-
ments

After opening the application initially and making the selection, the user can
further specify the inbound delivery regarding ASN reference or creation of
handling units.

For status tracking, we also recommend checking the SAP Fiori app Change
Inbound Deliveries:

34 / 143
1 Getting Started 4.5. POST-GOODS RECEIPT INTO ROD (RECEIVED ON DOCK)
STORAGE LOCATION IN SAP EWM
2 Introduction
4.5.1 Description
3 Master Data After creating the inbound delivery in the SAP EWM application, a first goods-
receipt posting into the ROD (received on dock) storage location takes place.
4 Business Process It means that goods have already been physically delivered and are in the
Description – goods receipt area, available to be stored into the warehouse. At this point of
Inbound Process
the process, goods are not yet available for unrestricted use, since they are
5 Business Process physically in the ROD storage location (e.g., goods receipt area) and still need
Description to be moved into the final storage area. The goods receipt (GR) posting can
for Outbound be executed either manually or automatically via PPF action, when activating
the inbound delivery in the EWM system (transaction /SCWM/PRDI).
6 Generic Part

7 Appendix This first goods-receipt posting into the ROD storage location is transmitted
back from SAP EWM to SAP ERP through the qRFC interface to update
8 Legal Require- ­inventory management stock values in the SAP ERP application.
ments
4.5.2 Business Process Monitoring
When goods receipt is posted into the ROD storage location in SAP EWM,
it is possible to confirm the posting via transaction /SCWM/PRDI. The status
of the field “goods receipt” turns “completed”:

The goods receipt posting into the ROD storage location will be transferred to
the SAP S/4HANA system via qRFC interface. After this transfer, the inbound
quantity should be already visible in the SAP S/4HANA system (transaction
MMBE), but not in the unrestricted stock since products still must be moved
to the final destination bin via warehouse tasks.

During the GR posting in SAP EWM, message IBDLV_CONFIRM_DECENTRAL

is sent to the corresponding SAP S/4HANA system by using qRFC interface.
This is triggered by a PPF action /SCWM/MSG_PRD_SEND, which can be
found in the inbound delivery.

35 / 143
1 Getting Started The following screenshot shows the transaction “Maintain Inbound Delivery”
/SCWM/PRDI: To analyze the PPF execution, it’s possible to check the log
2 Introduction
in the column “PPF Actions”:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix
After clicking the log item, the PPF execution is shown:
8 Legal Require-
ments

In the ERP system, an entry in the DLW inbound queue for a certain
document is created (when no direct processing/registration is activated).

After processing of this queue in SAP ERP with the function module
/SPE/INB_DELIVERY_CONFIRM_DEC, the GR in the ROD storage location
is posted and the status in the inbound delivery is updated.

36 / 143
1 Getting Started 4.5.3 Business Process Monitoring via SAP Fiori Apps
It is possible to use CDS View Inbound Delivery Item – Cube for status tracking,
2 Introduction
as well as making changes to inbound deliveries. The creation of warehouse
3 Master Data tasks and processing is available with the Change Inbound Deliveries App:

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound
After posting goods receipt, “Create Tasks” is possible:
6 Generic Part

7 Appendix

8 Legal Require-
ments

After creating the warehouse tasks, the user is able to directly jump into the
application: Process Warehouse Tasks (put-away).

37 / 143
1 Getting Started 4.6 CREATE AND PRINT HU WAREHOUSE TASK (MOVE PICK HUS
FROM STORAGE BIN TO PACK WORK CENTER)
2 Introduction
In this example of a business process step, a process-oriented storage control
3 Master Data with a deconsolidation step will be used. For each movement, an HU-WT (ware-
house task) will be created and for each packed material, one Product-WT.
4 Business Process
Description – 4.6.1 Description
Inbound Process
From the inbound delivery document (ID) in SAP EWM, HU-warehouse tasks
5 Business Process and still inactive product-warehouse tasks are created either manually or
Description automatically via PPF action to start the put-away process. Subsequently,
for Outbound these tasks are printed out and distributed to the resources that will execute
the assigned tasks physically. After that, the delivered goods are moved from
6 Generic Part
the goods receipt area to the deconsolidation area, where the first warehouse
7 Appendix internal put-away activities take place. In this step, the HU-WT determines
which HUs and quantity should be moved, where they should be picked from
8 Legal Require- (source location), and where they will be transported (destination location –
ments in this case, deconsolidation area).

4.6.2 Business Process Monitoring

The central tool for monitoring of warehouse tasks is the warehouse monitor
(transaction /SCWM/MON), using the following path: Inbound > Documents >
Inbound Delivery > Warehouse Task.

When double-clicking on the node “Warehouse Task,” an additional screen

opens, where several criteria for selection of warehouse tasks can be entered:

38 / 143
1 Getting Started A warehouse order is a collection of warehouse tasks that can be processed
by a single resource in the warehouse. In the warehouse management monitor,
2 Introduction
it is possible to monitor deconsolidation and put-away warehouse orders,
3 Master Data as well.

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

39 / 143
1 Getting Started It’s also possible to check the put-away workload via the monitor:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix
With the buttons, you can show/change warehouse orders, handling units,
8 Legal Require- and warehouse tasks according to their activity area.
ments
4.6.3 Business Process Monitoring via SAP Fiori Apps
See CDS View Inbound Delivery Item as well as the SAP Fiori app Change
Inbound Delivery (see Chapter 4.5.3)

4.7 CONFIRM HU WAREHOUSE TASK IN THE DECONSOLIDATION AREA

4.7.1 Description
When delivered goods have already been physically transported from the goods
receipt area (source area) to the deconsolidation area (destination area), a
corresponding HU-WT (warehouse task) must be confirmed in the SAP EWM
application. The confirmation of WTs informs SAP EWM that put-away has
been physically completely executed. Warehouse task confirmation can also
be performed using RF devices (transaction /SCWM/RFUI).

40 / 143
1 Getting Started When the inbound process is configured with a deconsolidation in the process-
oriented storage control, the goods will be deconsolidated (definition of inbound
2 Introduction
storage process in process-oriented storage control):
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Confirmation with RF devices: GUI devices are connected to the SAP system
just like any other client-dependent PC. Character-based devices (RF termi-
nals) are linked to the system through SAPConsole or ITS Mobile technology.
This concept is currently supported by the leading providers of RF terminals.

Confirmation without RF devices: Either the warehouse monitor in SAP EWM

(transaction SCWM/MON) or transaction /SCWM/TO_CONF (“Confirm Ware-
house Task”) can be used to confirm WTs in SAP EWM.

4.8 PERFORM REPACKING AND CREATE NEW HU/PRINT HU LABELS

4.8.1 Description
If there are any packaging specifications for the unpacked goods that should
be put away, the system can call packaging specification determination
automatically based on customized settings. In the same way, labels for the
corresponding handling units can be printed out automatically by the system
using PPF action.

The deconsolidation process can currently be supported only with the

desktop transaction /SCWM/DCONS or via RFUI.

41 / 143
1 Getting Started The following screenshot shows how the user can log into a deconsolidation
station and execute several tasks that are possible with transaction
2 Introduction
/SCWM/RFUI.
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
4.9 CLOSE HU AND ACTIVATE PRODUCT WAREHOUSE TASKS
4.9.1 Description
In the deconsolidation area, delivered handling units are physically unpacked,
and single products within them are sorted and repacked into new HUs
(optional) for further put-away into respective storage bins of the warehouse.
After repacking of goods, the original handling unit in which goods have been
delivered should be closed in SAP EWM. When closing the HU, product ware-
house, tasks are activated automatically for single goods. These product-WTs
determine the final storage bins where goods should be transported.

When working with the desktop transaction /SCWM/DCONS, the work

center DECO can be defined via customizing and can look like the following
screenshot. Close HU via the button in the red square:

42 / 143
1 Getting Started Optional Step: If an external non-SAP sub-system for management of an auto-
mated warehouse is involved in the process (material flow system), relevant
2 Introduction
information from the warehouse tasks created in SAP EWM might be required
3 Master Data and should be transferred to it. This WT information is transferred to the external
system through SAP standard IDoc interface /SCWM/WMTORD or via Telegram
4 Business Process using the MFS interface.
Description –
Inbound Process
Optional Step: When corresponding tasks are physically completed, the
5 Business Process completion confirmation is transmitted back from the external system into
Description SAP EWM through SAP standard IDoc interface /SCWM/WMTOCO as well
for Outbound as via Telegram using the MFS interface, which updates the status of the WT
in SAP EWM to “confirmed.”
6 Generic Part

7 Appendix 4.10 RFUI: CONFIRM PRODUCT WAREHOUSE TASKS AT FINAL

DESTINATION
8 Legal Require- 4.10.1 Description
ments After goods have already been moved to the final storage bin, product WO
(warehouse order) and WTs should be confirmed to inform SAP EWM that
tasks are physically completed. Warehouse orders (and corresponding ware-
house tasks assigned to them) can be confirmed either via the warehouse
monitor in SAP EWM (transaction /SCWM/MON), transaction /SCWM/
TO_CONF (Confirm Warehouse Task), or via RF device. The user can confirm
corresponding warehouse orders via RF device.

4.11 POSTING CHANGE (ROD > AFS)

4.11.1 Description
When the WT is confirmed in the SAP EWM application, an automatic final-stock
posting from the ROD storage location into the available-for-sales stock (AFS)
takes place. This means that goods have already been stored in their final stor-
age bin. Finally, this posting is also replicated automatically into SAP ERP via
qRFC interface to update inventory management stock values and complete the
inbound process.

4.11.2 Business Process Monitoring

During the ROD > AFS posting change in SAP EWM, the inbound delivery
confirmation message is sent to the corresponding SAP S/4HANA system
by using qRFC Interface. This is triggered by a PPF action /SCWM/
MSG_PRD_SEND, which can be found in the inbound delivery.

43 / 143
1 Getting Started The following screenshots show the PPF processing log:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

In SAP ERP, an entry in the DLW queue for the corresponding inbound
delivery document is created.

44 / 143
1 Getting Started In order to avoid any stock inconsistencies between SAP ERP and SAP EWM,
monitoring of this queue is essential. Monitoring can be done using: Warehouse
2 Introduction
Monitor (SCWM/MON) > Tools > Message Queue:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

After executing the selection:

45 / 143
1 Getting Started Transaction /SCWM/ERP_STOCKCHECK can be used to analyze/monitor
stock differences between the SAP S/4HANA core and SAP EWM.
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

4.11.3 Business Process Monitoring via SAP Fiori Apps

/SCWM/ERP_STOCKCHECK is only available as an SAP Fiori–enabled
transaction.

46 / 143
 5 B
 usiness Process Description
for Outbound
1 Getting Started A range of documents are used in the SAP system to map the individual steps
in the outbound/goods issue process. These documents contain relevant infor-
2 Introduction
mation on the business transactions. The outbound process begins in SAP ERP
3 Master Data when the outbound delivery document is created. If one or more items in the
outbound delivery document are relevant to SAP EWM, the delivery document
4 Business Process is replicated to SAP EWM.
Description –
Inbound Process
In SAP EWM, the document is known as the outbound delivery request (ODR).
5 Business Process The outbound delivery request is a copy of the outbound delivery document in
Description SAP ERP. It carries the same document number. Based on the configuration
for Outbound related to the post-processing framework (PPF), the system then creates the
outbound delivery order document (ODO).
6 Generic Part

7 Appendix This document contains additional data relevant to SAP EWM, determined
based on the service profiles associated with the outbound-delivery document
8 Legal Require- type and delivery category. This is the warehouse request document for the
ments goods issue process in SAP EWM. From the outbound delivery order, the ware-
house tasks are created to control the picking and other associated processes
such as packing, staging, and loading.

SAP ERP SAP EWM

Sales order

[Outbound delivery
Outbound delivery
Replication request]

Outbound delivery
order

Create picking
Outbound delivery
warehouse task

Confirm picking
warehouse task

Outbound delivery Goods issue

Confirmation

Remark: In an embedded deployment of SAP EWM, the ODR document does

47 / 143 not exist; therefore the outbound delivery order will be directly created.
1 Getting Started 5.1 SALES ORDER PROCESS IN SAP ERP
5.1.1 Description
2 Introduction

3 Master Data In SAP ERP, every sales activity is documented by a sales document. Various
business transactions in sales, shipping, and billing can be mapped by means
4 Business Process of individual configured document types. Each document can be tracked by
Description – an overall status that indicates the processing stage that the document has
Inbound Process
reached. The overall status is determined based on the various statuses in
5 Business Process the document.
Description
for Outbound In addition, the SD processing can be influenced with multiple decentralized
applications such as SAP Customer Relationship Management (SAP CRM),
6 Generic Part
global available to promise in the SAP Advanced Planning and Optimization
7 Appendix component, SAP Integrated Business Planning (SAP IBP), SAP TM, and
SAP EWM.
8 Legal Require-
ments Available transactions:
• VA01: Create sales order document
• VA02: Change sales order document
• VA03: Display sales document
• VA05: List of sales orders

Available SAP Fiori apps:

• Manage sales orders (version 2)
• Track sales orders
• Sales order fulfillment issues (version 2)

Sales documents such as sales orders are created during presales and order
processing. Requests for quotations, contracts, scheduling agreements, and
standard sales orders are all examples of sales document types.

48 / 143
1 Getting Started 5.1.2 Business Process Monitoring
For display of sales order documents, transaction VA03 can be used.
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

If the sales document number is not available, transaction VA05 (list of sales
orders) can also be used. The transaction offers the user more selection
criteria compared to transaction VA03.

49 / 143
1 Getting Started 5.1.3 Business Process Monitoring via SAP Fiori Apps
There are multiple SAP Fiori apps to keep track of sales orders. With the Track
2 Introduction
Sales Order SAP Fiori app, the supervisor is able to see the status of the sales
3 Master Data order and can directly check possible fulfillment issues:

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
When selecting a sales document, possible blocking reasons can be checked:

50 / 143
1 Getting Started The issue can be resolved, in this case, by removing the billing block.

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

To get a fast overview over existing issues with sales orders, the application
Sales Order Fulfillment Issues (Version 2) can be used:

51 / 143
1 Getting Started To generally handle sales orders: Use application: Manage Sales Orders –
Version 2:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

5.2 OUTBOUND PROCESSING DOCUMENT IN SAP ERP

5.2.1 Description
Outbound deliveries can be created in SAP ERP in several ways: via VL01A, via
VL01NO (create outbound delivery without reference), via VL10B (for stock
transfer orders), or VL10A (based on sales order). When an outbound delivery
document is created, SAP ERP checks each line item to see if it is relevant for
warehouse management processing. This check consists of matching the plant
and storage location codes from the delivery line item to the plant-storage
location to warehouse assignment table in customizing. If the check is positive,
the system distributes the outbound delivery document to SAP EWM. There
are two ways to distribute the outbound delivery from SAP ERP to SAP EWM:
• After saving the outbound delivery document, this delivery is distributed
immediately to SAP EWM.
• Collect outbound deliveries and release all documents manually in trans-
action VL06O (Outbound Delivery Monitor) via subnode “For Distribution.”

The distribution of delivery documents happens via qRFC (queued remote

function call). Parallel to the creation and saving of an outbound delivery,
SAP ERP sends a message to SAP EWM for creation of an outbound delivery
request.

52 / 143
1 Getting Started Relevant transactions
• VL01N: Create outbound delivery with order reference
2 Introduction
• VL01NO: Create outbound delivery without order reference
3 Master Data • VL02N: Change outbound delivery
• VL03N: Display outbound delivery
4 Business Process • VL10A: Sales orders: fast display
Description – • VL10B: Purchase orders: fast display
Inbound Process

5 Business Process Relevant SAP Fiori apps:

Description • Manage outbound delivieries in SAP S/4HANA
for Outbound • Run outbound process

6 Generic Part
5.2.2 Business Process Monitoring
7 Appendix For checking and monitoring outbound deliveries, the following transactions
can be used:
8 Legal Require- • VL02N: Change outbound delivery
ments • VL03N: Display outbound delivery
• VL06O: Outbound delivery monitor

Transaction VL02N (change outbound delivery):

53 / 143
1 Getting Started Transaction VL06O (outbound delivery monitor):

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

54 / 143
1 Getting Started After selecting “List Outbound Delivery,” the following screen appears:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Further selection options:

55 / 143
1 Getting Started 5.2.3 Business Process Monitoring via SAP Fiori Apps
Outbound felivery processing can also be monitored by using the application
2 Introduction
Manage Outbound Deliveries: In SAP Fiori.
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

5.3 OUTBOUND DELIVERY REQUEST (ODR) IN SAP EWM

5.3.1 Description
Unchecked deliveries that have been converted in SAP ERP to checked
deliveries, or outbound deliveries created in SAP ERP from sales documents
that are relevant for processing in a warehouse in SAP EWM, will be replicated
to SAP EWM as an outbound delivery request (ODR) document. The outbound
delivery request contains all the relevant logistics data in the outbound delivery
process right from the origin of the outbound delivery process (sales order,
for example). In an embedded scenario, the outbound delivery order (ODO)
will be created directly, as no ODR exists.

The warehouse request is a document that enables the processing of

warehouse activities for a specific product, e.g., picking.

During automatic creation and saving of the warehouse request, SAP EWM
triggers the following:
• The mapping of delivery data from SAP ERP onto the delivery data in
SAP EWM
• Data enrichment
• Wave assignment, depending on customizing
• Determination of a warehouse process type, which controls the processing of
a warehouse task in SAP EWM, such as whether SAP EWM is to immediately
confirm a warehouse task.

For checking ODRs, use transaction /SCWM/PRDO > button “Outbound

56 / 143 Delivery Request.”
1 Getting Started The following diagram describes the basic document creation and process
flow related to outbound delivery processing.
2 Introduction

3 Master Data Embedded scenario:

4 Business Process
Description – SAP S/4HANA with embedded SAP EWM
Inbound Process
Sales order
5 Business Process
Description
for Outbound
Outbound delivery
6 Generic Part

7 Appendix Outbound delivery

order
8 Legal Require-
ments
Create picking
warehouse task

Confirm picking
warehouse task

Goods issue

Outbound delivery

57 / 143
1 Getting Started Decentral installation:

2 Introduction
SAP ERP SAP EWM
3 Master Data

4 Business Process Sales order

Description –
Inbound Process
[Outbound delivery
5 Business Process Outbound delivery
Replication request]
Description
for Outbound
Outbound delivery
6 Generic Part order

7 Appendix
Create picking
Outbound delivery
8 Legal Require- warehouse task
ments

Confirm picking
warehouse task

Outbound delivery Goods issue

Confirmation

58 / 143
1 Getting Started 5.3.2 Business Process Monitoring
Selection for active outbound delivery requests (ODR)
2 Introduction
The outbound delivery request can be selected in SAP EWM via transaction
3 Master Data /SCWM/ODR (maintain outbound delivery request) via the document in
SAP ERP (if available):
4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

If the document number in SAP ERP is not available, different search options
are available using the “Open Advanced Search” button:
• On tab “Search Crit.1” can be selected via “Documents” and “Product”
specific data
• On tab “Search Crit.2” can be selected via “Partner, Locations, and
Organizational Data” and “Administration Data”
• On tab “Search Crit.3” can be selected via “Dynamic Selection Criteria
(e.g., date/time)” and from which “Data Source” should be selected.

59 / 143
1 Getting Started Selection for inactive outbound delivery requests (ODR)
If no “active” ODR can be selected, then the document is possibly inactive.
2 Introduction
For selection of inactive ODR, the search criteria must be changed:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

The reason for an inactive ODR could be an unsuccessful check or missing

data for activation – for example, a missing partner role, missing master data
(batches, products), and so on.

Maintain the missing data and activate the ODR document by pressing button
“Activate.”

5.3.3 Business Process Monitoring via SAP Fiori Apps

Currently it is only possible to monitor outbound delivery requests in the
SAP Fiori–enabled application of /SCWM/ODR.

60 / 143
1 Getting Started 5.4 OUTBOUND DELIVERY ORDER (ODO)
5.4.1 Description
2 Introduction
An outbound delivery order (ODO) is created automatically from the out-
3 Master Data bound delivery request via post processing framework (PPF). The outbound
delivery order is a document containing all the data required for triggering
4 Business Process and monitoring the complete outbound delivery process. The process starts
Description – with planning activities for the outbound delivery and continues with picking
Inbound Process
until the finished goods have been loaded and sent. The outbound delivery
5 Business Process order can be used to execute the following actions:
Description • Creation of the outbound delivery
for Outbound • Creation of warehouse tasks to pick the delivery
• Cancellation of already picked goods
6 Generic Part
• Loading the delivery
7 Appendix • Canceling the delivery loading
• Setting the status “Leave Yard”
8 Legal Require- • Adjusting the delivery quantity to the picked quantity
ments • Posting a goods movement
• Canceling a goods movement
• Creating and deleting items

Selection of documents in transcations maintain outbound delivery order

/SCWM/PRDO:

61 / 143
1 Getting Started After selecting an outbound delivery order, the items as well as many other
information can be shown:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

5.4.2 Business Process Monitoring

Via user interface transaction
For checking ODOs, use transaction /SCWM/PRDO; button “Outbound
Delivery Order.” The following selection options can be used:
• ODO – Outbound delivery order
• ERP-documents/LE-deliveries
• Production/manufacturing orders
• Purchase/sales order

If no ODRs can be selected or there is no search option for outbound delivery

orders (there is no result after the selection), then the qRFC-Monitor must
be checked for stuck queues. Check the inbound queue in SAP EWM (SMQ2)
at first. Enter transaction SMQ2:

62 / 143
1 Getting Started Use button “Execute” (F8) for searching a document with queue
name DLV*. The queue appears as follows (example queue:
2 Introduction
DLVSQKVCLNT1100180001544):
3 Master Data
DLVS: “Deliveries”
4 Business Process QKVCLNT110: related system and client
Description – 80082418: SAP ERP document number (outbound delivery)
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

To get further information to a queue, double-click on the queue name.

63 / 143
1 Getting Started Double-click the field “Status,” and an additional pop-up with further information
is shown.
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

If the information is not detailed enough, double-click on “queue name”:

Double-click on field “Status Text” (application log), and the application log
to the queue will be shown (also available via transaction SLG1).

If the search was unsuccessful, check the outbound queue in SAP ERP (SMQ1)
for stuck queues, as well:

64 / 143
1 Getting Started Via warehouse monitor
The most important transaction for monitoring outbound delivery orders
2 Introduction
in SAP EWM is /SCWM/MON: warehouse management monitor. Use the
3 Master Data following node: Outbound > Documents > Outbound Delivery Order.

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Double-click on node “Outbound Delivery Order” and a new screen opens:

65 / 143
1 Getting Started After entering the selection criteria (e.g., delivery date, picking status, document
type), the relevant documents are selected and displayed:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require- After pressing the hot spot in field “Document,” transaction /SCWM/PRDO
ments opens, the user can perform further checks.

66 / 143
1 Getting Started 5.4.3 Business Process via SAP Fiori Apps
There are multiple applications supporting you in monitoring outbound delivery
2 Introduction
orders (ODO) and their progress. The first application is Run Outbound Process.
3 Master Data Here you have an overview of the ODO statuses as well as their picking progress:

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

With the selection of one ODO, further information will be shown:

67 / 143
1 Getting Started The second application is warehouse KPIs, with the KPIs listed in Chapter 2.4:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

5.5 WAVE MANAGEMENT

5.5.1 Description
Wave management is not mandatory; it’s an optional step and can be used for
grouping warehouse request items to control warehouse activities, for example,
picking or posting changes. There are two ways to assign the warehouse
request items to waves: manually or automatically. Automatic wave assign-
ment is triggered by a customized setting in the warehouse process type.
A warehouse process type is assigned to every warehouse request document.
SAP EWM uses the condition technique to determine wave templates (Trans-
action: /SCWM/WDGCM – wave determination general condition maintenance).
This enables SAP EWM to determine which wave template corresponds to
certain data from the header, item, or split item of a warehouse request.

68 / 143
1 Getting Started Wave assignment can be done manually in transaction /SCWM/WAVE.

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

These groupings are then processed together in subsequent processes,

for example, the transfer of all warehouse request items assigned to a wave
to warehouse task creation at the same time.

5.5.2 Business Monitoring

The transaction for processing and monitoring waves in detail is /SCWM/WAVE
(wave management):

69 / 143
1 Getting Started After entering one of the selection criteria and pressing F8 (“Perform Search”),
the waves are shown:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Warehouse Monitor (/SCWM/MON)

The most important transaction for monitoring waves in SAP EWM is
/SCWM/MON (warehouse management monitor). The waves can be
selected using the following path: Documents > Wave.

70 / 143
1 Getting Started After pressing the button “Wave Item,” all items assigned to the marked wave
are shown. To display warehouse orders or warehouse tasks, the button
2 Introduction
“Warehouse Order” or “Warehouse Tasks” can be used. After pushing the
3 Master Data button “Wave Detail,” a summarized view of wave detail is shown.

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

5.5.3 Business Process Monitoring via SAP Fiori Apps

/SCWM/WAVE is available only as an SAP Fiori–enabled transaction.

5.6 WAVE PROCESSING

5.6.1 Description
Waves can be released multiple times. For example, if the wave is released,
but SAP EWM can only generate some of the required warehouse tasks since
there is not enough stock, the wave can be released again at a later point.

For wave release in the easy access screen, the following path must be chosen:
Extended Warehouse Management > Work Scheduling > Wave Management >
Maintain Waves.

71 / 143
1 Getting Started Alternatively, transaction /SCWM/WAVE can be entered directly.

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

When SAP EWM releases the wave, it creates the warehouse tasks at the same
time. SAP EWM creates warehouse orders based on defined warehouse-order
creation rules in order to create work packages for the warehouse workers.

Waves can be released in three ways:

• Automatically Wave Release
SAP EWM creates a job that automatically releases waves on the release
day and at the release time.
• Immediate
The wave will be released immediately after creation.
• Manually
Waves can be released manually at any point in time in the warehouse moni-
tor (/SCWM/MON) or in wave processing (/SCWM/WAVE). During manual
wave release, locked waves can also be released. In this case, SAP EWM
sets the status “Locked” for the warehouse orders created. As a result, these
warehouse orders are locked for further processing for the time being.

72 / 143
1 Getting Started The wave template and the release method can also be maintained in
transaction /SCWM/WAVETMP:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
Listed below are some of the ways wave processing can be used to control
warehouse activities:
• Lock wave
Set the status of the selected waves to “On Hold.” Waves of this status
cannot be released until their status is changed back to “Initial.”
• Unlock wave
Set the status of the selected waves to “Initial.” This method can only be
performed on waves of status “On Hold.”
• Delete wave
Deletion of the selected wave. All warehouse request items are removed
from the wave; SAP EWM deletes a wave completely. The wave then also
can’t be archived.
• Merge wave
Merges the selected waves into one wave. SAP EWM assigns warehouse
request items to the waves. When the waves are merged, SAP EWM assigns
all the warehouse request items for the selected waves to the first wave
selected.
• Change wave
Enable the attributes of a selected wave to be changed.
• Release wave
Releases one or more selected waves at the same time. Only waves
of status “Initial” can be released.
• Subsystem
Activates the WOs and TOs sent to a subsystem (non-SAP system).

73 / 143
1 Getting Started • Split (wave item)
Splits the selected wave items from their waves and creates a new wave
2 Introduction
for them. A warehouse request item can be selected and removed from
3 Master Data the current wave. SAP EWM creates a copy of the wave and assigns the
warehouse request item to the copy.
4 Business Process • Simulate wave
Description – The release of the wave is simulated, and the log is written in the background
Inbound Process
and can be shown via “Display Simulation Log.”
5 Business Process • Unassign (wave item)
Description Unassign the selected wave items from the wave.
for Outbound • Assign to wave
Enables assignment of one or more selected wave items or warehouse
6 Generic Part
request items to a specified wave.
7 Appendix
5.6.2 Business Process Monitoring
8 Legal Require- The activities described in wave processing above can also be initiated
ments from the warehouse monitor (/SCWM/MON) by entering this way:
Documents > Wave.

74 / 143
1 Getting Started The wave release can also be simulated using other methods. A log with further
information will be shown:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
With the warehouse management monitor /SCWM/MON, it’s possible to keep
track of overdue waves. The check is based on the wave release date and the
wave status (initial, locked, or released with defect).

The key figure is under the Alert node > “Overdue Wave”:

75 / 143
1 Getting Started Wave CDS view
Available with the Wave CDS view:
2 Introduction
• How many wave items are there in my warehouse?
3 Master Data • What is the status of my waves?
• When are my waves complete?
4 Business Process • When is the release date and time of waves?
Description – • When is the cutoff date and time of waves?
Inbound Process
• When is the packing completion date and time of waves?
5 Business Process
Description Usage of this CDS View depends highly on customer requirements.
for Outbound
5.6.3 Business Process Monitoring via SAP Fiori Apps
6 Generic Part
No SAP Fiori apps are available for monitoring of waves.
7 Appendix
5.7 CREATION OF WAREHOUSE TASKS FOR WAREHOUSE
8 Legal Require- REQUEST/WAREHOUSE ORDER
ments 5.7.1 Description
HU-warehouse task creation (move pick HUs to pack work center)
SAP EWM uses this function so that when the application or a user releases
a wave, SAP EWM simultaneously creates warehouse tasks for stock removal.
SAP EWM creates warehouse orders according to the warehouse tasks to
assemble work packages for the individual warehouse workers. Instead of
this standard creation of warehouse tasks through wave release, you can
also create a warehouse task as follows:
• Manually, with transaction /SCWM/TODLV
• Automatically, by calling a post-processing framework (PPF) action

Each warehouse task is assigned a warehouse process type. Outbound tasks

can be either product or handling-unit tasks. HU warehouse tasks are used
to move handling units. A handling unit warehouse task is based on goods
movements and contains all the information required to execute the physical
transfer of HUs within the warehouse from one storage bin to another.

For moving the HUs in the warehouse, a storage process with its individual
storage process steps has to be defined. For that, the process-oriented as
well as layout-oriented methods for storage control can be used. The goal of
storage control is to display the complex stock-removal process steps based
on the processes or the layout data. During stock removal, an individual pro-
cess step can be executed on a single- or multi-level basis (that is, through
intermediate storage types). The SAP standard process-oriented storage con-
trol only works with HUs. The relevant HU must be known to storage control.

76 / 143
1 Getting Started Only the internal storage process steps for the stock-removal process
can be entered in the following sequence:
2 Introduction
• Remove from stock (pick)
3 Master Data • Pack
• Stage
4 Business Process • Load
Description –
Inbound Process
The following screenshot shows the setup for process-oriented storage
5 Business Process controls:
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
Warehouse monitor /SCWM/MON:

77 / 143
1 Getting Started /SCWM/WAVE:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments Manual creation of warehouse tasks
A warehouse task can be created either with reference to a warehouse request,
such as the outbound delivery order (using transaction /SCWM/TODLV (create
warehouse task for stock removal), or without a reference document, for
example, for internal goods movements by using transaction /SCWM/ADHU
(ad hoc movement handling unit) or /SCWM/ADPROD (ad hoc movement
product).

Alternatively, use transaction /SCWM/PRDO maintain outbound delivery

order (follow on Functions > Warehouse Task) or directly enter transaction
/SCWM/TODLV for warehouse task creation:

78 / 143
1 Getting Started /SCWM/ADPROD – Create product warehouse task

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Functionalities of warehouse task

The following methods are available for processing/manipulation and
monitoring of warehouse tasks:
• Simulate WO creation
Simulates the warehouse order creation out of multiple warehouse tasks
according to the constraints defined in customizing; see also warehouse
order
• Display WT log
Displays the application log for a selected warehouse task
• Split WT from WO
Splits one or more selected warehouse tasks from a specified warehouse
order
• Assign WT
Enables assignment of one or more selected warehouse tasks to a specified
warehouse order
• Unassign WT
Unassigns one or more selected warehouse tasks from a specified ware-
house order. To execute the warehouse tasks, they must be assigned
to a warehouse order.
• Confirm in WT foreground
Enables confirming in the foreground one or more selected warehouse
tasks or warehouse orders (transaction /SCWM/TO_CONF)

79 / 143
1 Getting Started • Confirm WT in background
Confirms in the background one or more selected warehouse tasks
2 Introduction
or warehouse order
3 Master Data • Cancel WT
Enables cancellation of a warehouse task
4 Business Process • Show exceptions
Description – Check exceptions for specific warehouse tasks
Inbound Process
• Show value
5 Business Process Shows the key figures of the warehouse task
Description • Assign WT to packing proposal
for Outbound Enables assignment of one or more selected warehouse tasks to
a specified packing proposal
6 Generic Part
• Confirm WT with exception
7 Appendix Confirms in the background one or more selected warehouse tasks
with an exception
8 Legal Require-
ments

Warehouse order
This function groups together warehouse tasks into warehouse orders. According
to the customized ruleset optimized packages will be created for the warehouse
employee. For warehouse order creation, warehouse order creation rules with
their relevant criteria must be defined. Warehouse order creation is particularly
suitable for optimizing processes for picking. A warehouse order consists of
one or more warehouse tasks.

80 / 143
1 Getting Started A wave usually consists of several deliveriey items. After the wave and wave
item have been released (either immediately, automatically via Job or manu-
2 Introduction
ally via User), SAP EWM creates warehouse tasks. SAP EWM groups the ware-
3 Master Data house tasks into warehouse orders, according to the warehouse order creation
rules that have been defined. A warehouse order can contain warehouse tasks
4 Business Process from more than one delivery.
Description –
Inbound Process
Warehouse orders can be created as locked resulting from the wave release.
5 Business Process It’s not possible to initially continue to process these warehouse orders. A
Description method in the warehouse management monitor (/SCWM/MON) to release
for Outbound the lock on the warehouse orders can be used. If you want to release the lock
on a warehouse order, you can select the “Unlock WO” method, for example,
6 Generic Part
in the warehouse management monitor in the dialog structure under the node:
7 Appendix Documents > Warehouse Order > using the “More Methods” action menu
(see Chapter Wave Processing).
8 Legal Require-
ments

When grouping warehouse tasks into warehouse orders, SAP EWM uses the
search sequence for WO creation, for example, first rule A, then B, then C. SAP
EWM works through the WO creation rules in sequence, as defined in custom-
izing for each activity area. It is possible to change the sequence subsequently.

Filters and limit values control which and how many warehouse tasks SAP EWM
groups together into a warehouse order.

The individual WO creation rule can contain sorting rules. As soon as SAP EWM
applies a WO creation rule, it sorts the warehouse tasks according to the defined
sorting rules.
81 / 143
1 Getting Started Because work packages for the warehouse employee are based on warehouse
orders containing several warehouse tasks, user-defined WO creation rules
2 Introduction
have been applied. All warehouse tasks must be assigned to a warehouse
3 Master Data order. If SAP EWM has applied all the user-defined WO creation rules for the
search sequence, and there are still unprocessed warehouse tasks, the system
4 Business Process then uses a default warehouse order creation rule (DEF) or in case it found a
Description – WOCR but cannot apply it UNDE. This rule creates warehouse orders for the
Inbound Process
remaining warehouse tasks. SAP EWM summarizes these warehouse tasks
5 Business Process according to the following criteria:
Description • Activity area
for Outbound • Queue
• Consolidation group
6 Generic Part

7 Appendix Functionalities of warehouse orders (WO)

The following methods are available for processing/manipulation and
8 Legal Require- monitoring of warehouse orders/warehouse tasks:
ments • Simulate WO
Enables you to simulate warehouse-order creation for one or more selected
warehouse tasks, based on a specified warehouse-order creation rule. If none
is specified, the system will attempt to determine a WOCR according to the
search sequence for warehouse-order creation rules per activity area.
• Split from WO
Enables you to unassign one or more warehouse tasks from a warehouse
order and grouping them into a newly created warehouse order. Using this
method, you can determine the warehouse-order creation rule. If none is
specified, the system will attempt to determine a WOCR according to the
search sequence for WO creation rules per activity area. In addition, a reason
for the split, which is stored in the exception log for warehouse orders, can
be specified.
• Display WO log
Displays the application log for a selected WO.
• Merge WOs
Enables you to merge selected open WOs, which unassigns the WTs from
the WOs, and groups them into a newly created WO. Using this method, you
can determine the warehouse creation rule. If none is specified, the system
will attempt to determine one pursuant to the search sequence for WO
creation rules per activity area. You can also specify a reason for the merge,
which is stored in the exception log for WOs.
• Print
Automatically print lists during creation of warehouse orders and warehouse
tasks, according to your customizing settings. These lists contain information
about the source and destination storage bin for product movements.

82 / 143
1 Getting Started • Reprint WO
Enables you to reprint HU (handling unit), WT, or WO details
2 Introduction
• Lock-WO
3 Master Data Lock a WO with the status B (locked). As a result, the WO cannot be
processed further until it is unlocked.
4 Business Process • Unlock-WO
Description – Enables unlocking locked WOs and releasing them for further processing.
Inbound Process
• Assign resource
5 Business Process Enables you to assign/unassign a resource to/from one or more selected
Description WOs.
for Outbound • Unassign resource
Enables you to assign/unassign a resource to/from one or more selected
6 Generic Part
WOs.
7 Appendix • Change queue
Enables you to change the queue to which the selected WOs are assigned.
8 Legal Require- • Change LSD
ments Changes the latest time by which warehouse order execution should
commence so that it is completed by the due date.
• Add WO
Adds an empty WO to a super WO (loading/unloading scenario).
• Confirm foreground
Enables you to confirm in the foreground one or more selected WTs or
WOs (transaction /SCWM/TO_CONF).
• Confirm background
Confirms in the background one or more selected WTs or WOs.
• Cancel WO
Enables the cancellation of selected WOs and their respective warehouse
tasks.

83 / 143
1 Getting Started 5.7.2 Business Process Monitoring
To manage warehouse orders and warehouse tasks as described above in
2 Introduction
the warehouse management monitor, follow the dialog structure under the
3 Master Data node: Documents > Warehouse Tasks

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Documents > Warehouse Tasks, after selection using the “More Methods”
action menu:

84 / 143
1 Getting Started Warehouse monitor
Also in the warehouse management monitor: Documents > Warehouse Order,
2 Introduction
after selection using the “More Methods” action menu:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

To monitor execution in specific areas, there are subnodes, for example,

under Outbound > Processes > Picking:

85 / 143
1 Getting Started From the “Alert” sub-node it’s also possible to track overdue tasks and orders:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

It is also possible with variants in the warehouse monitor to determine the

throughput in the picking operations within a defined time period by using
the following key figures:
• Created warehouse tasks
• Confirmed warehouse tasks
• Confirmed warehouse orders
• Confirmed warehouse task items with exception

For monitoring setup in the warehouse management monitor, follow the detailed
procedure provided in the linked blog post: Advanced Features in SAP EWM
Warehouse Management Monitor. A warehouse order is a collection of ware-
house tasks that can be processed by a single resource in the warehouse.

86 / 143
1 Getting Started 5.7.3 Business Process Monitoring via SAP Fiori Apps
Warehouse KPIs enable the user to see directly where the warehouse tasks
2 Introduction
are open or overdue. From here the supervisor can monitor and manage
3 Master Data these tasks.

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

There are also the CDS views for Warehouse Tasks and Warehouse Orders
available, for example:
• How many warehouse tasks are there in my warehouse?
• How many warehouse task items are there in my warehouse?
• What is the total volume of warehouse task items?
• What is the total net weight of warehouse task items?
• What is the actual product quantity in base or alternative unit of measure
(UoM)?
• What is the difference in product quantity in base or alternative UoM?
• What is the target product quantity in base or alternative UoM?

87 / 143
1 Getting Started 5.8 CONFIRMATION OF WAREHOUSE TASKS
5.8.1 Description
2 Introduction
Confirmation with Radio Frequency (RF) Device
3 Master Data It’s possible to pick using a radio frequency (RF) presentation device. The pick
point is defined as a work center (packaging work center) in SAP EWM. This
4 Business Process function is part of the goods issue process. In this type of picking, the handling
Description – unit (HU) arrives at the warehouse worker (goods-to-person). In standard RF
Inbound Process
picking, it is the other way round: the warehouse worker follows a specified
5 Business Process picking path and picks out of HUs (person-to-goods). At the pick point, you
Description withdraw products from an (HU) and pack these into pick-handling units.
for Outbound
The RF framework supports GUI devices, character-based devices, as well as
6 Generic Part
browser-based devices. GUI devices are connected to the SAP system just like
7 Appendix any other client-dependent PC.

8 Legal Require- The prerequisite for using RF is that the resource management and queue
ments management have been configured and customized. Furthermore, the user
must be logged on to the RF environment (transaction /SCWM/RFUI). During
warehouse order creation the queue assignment will be performed based
on the following parameters:
• Source activity area
• Destination activity area
• Bin access type
• Warehouse process type
• Queues

The search is performed according to the access sequence, with the initial
search being for an entry with all of these parameter values specified. If no
queue is found, the queue determination table is read again, according to
the next entry in the sequence.

88 / 143
1 Getting Started 5.9 RF-PICKING PROCESS OVERVIEW
For execution and confirmation of warehouse tasks, different possibilities exist
2 Introduction
in the RF main menu. Enter transaction /SCWM/RFUI and navigate through
3 Master Data the SAP standard menu. For example:

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

System- System- Picking Picking Picking

Guided Picking Guided Picking by WR by WO by HU
by Queue
1. After logging on to an RF presentation device, choose 04 Outbound > 01 Picking
2. Choose Choose Choose Choose Choose
01 System- 02 System- 03 Pick by WR 04 Pick by WO 05 Pick by HU
Guided Picking Guided by Queue
3. Select a queue Select a ware- Select a WO Select an HU
house request
4. The system selects and locks a WO for selection, according to the WO selection mechanism.
The pick HU introduction screen appears.
5. If HUs or packaging products are assigned to the WO, an existing HU can be used. Other-
wise, a new one must be created by entering/scanning a packaging product, printing labels,
and scanning the HU numbers.
6. After having created one or multiple pick HUs, the source screen of the first WT of the WO
will be shown. Depending on the WT, one of the following screens is displayed:
• Pick product screen – if the WT is for picking a quantity of product from a non-bulk-
storage type
• Pick bulk product screen – if the WT is for picking a quantity of product from a bulk-
storage type
• Pick HU screen – if the WT is for picking HUs not known in the TO
7. In the case of the pick product screen, the source bin, source HU, product, quantity, and
destination HU (or position) must be validated. In the case of the pick HU screen, the source
bin, source HU, and destination HU must be validated. The pick bulk product screen is the
same, except that the source HU number must be scanned.
8. After all products are picked and have been put into the resource‘s pick HUs, the place HU
screen appears. In case of no pick HU, the place product screen appears.
9. In the case of the place product screen, the destination bin, position, product, and quantity
must be validated. In the case of the place HU screen, you validate the destination bin and
destination HU.
89 / 143
1 Getting Started These menus can be designed via RF menu manager in the customizing:
EWM > Mobile Data Entry > Radio Frequency (RF) Framework > RF Menu
2 Introduction
Manager
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Alternative: Confirmation Without RF

It’s also possible to confirm and save all warehouse tasks in one go, so called in
the background. If data is to be changed, it’s also possible to adapt it manually
and then save it; in other words, confirm the individual warehouse tasks in the
foreground. The following describes the change options available for manual
confirmation in the foreground.

When a warehouse task is confirmed manually, the destination must be entered.

It’s only possible to define one destination location; this means it’s either the
destination storage bin, destination resource, or destination transportation
unit. If SAP EWM has already determined and specified a destination location,
it’s possible to change the destination location. In this case, an exception code
must be applied. If products are packed into a destination handling unit, this
destination handling unit must be used during warehouse task confirmation.
If SAP EWM has already determined a destination handling unit, you can
change it. In this case, an exception must be used.

If SAP EWM generates a warehouse task and was not yet able to determine
a source handling unit, the source HU must be defined. If nested handling
units are used, the specific source handling unit must also be defined while
confirming the warehouse task.

90 / 143
1 Getting Started Depending on product or an HU warehouse task, different transactions
can be used for warehouse task confirmation:
2 Introduction
• /SCWM/ADPROD – Create product warehouse task
3 Master Data • /SCWM/ADHU – Create handling unit warehouse task
• /SCWM/TO_CONF – Confirm warehouse task
4 Business Process
Description – Alternatively the SAP Fiori app Process Warehouse Tasks can be used.
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

The warehouse monitor (transaction /SCWM/MON) can also be used to confirm

a warehouse task using the following node: Documents > Warehouse Task.
After selecting a specific warehouse task in the status “open,” it is possible
to use: “More methods”> “Confirmation in Foreground” or “Confir­mation in
Background.” Confirm in background confirms the warehouse task imme­
diately while in foreground, the necessary data has to be entered.

91 / 143
1 Getting Started 5.9.1 Business Process Monitoring
Confirmed warehouse task can be monitored and selected via the warehouse
2 Introduction
monitor (/SCWM/MON) using the following path: Documents > Warehouse
3 Master Data Task. To monitor all “confirmed” warehouse tasks in a specific time frame,
the selection criteria “Confirmed WTs” must be marked:
4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

92 / 143
1 Getting Started The result is a list with all warehouse task for the selected time frame with
status “C”(confirmed) in column “Status”:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix
With the release of SAP S/4HANA 2021, RF logging was introduced. This
8 Legal Require- functionality enables you to analyze cases of errors via detailed tracking of
ments resources in the RF. The RF log is accessible via the warehouse management
monitor: Resource Management > RF Log

The activation of the RF log is via T-Code /SCWM/RFLOGACT. For further

information, refer to this blog post: RF Logging in SAP EWM

93 / 143
1 Getting Started 5.10 PACKING
5.10.1 Description
2 Introduction
Packing in the outbound processes generally involves the removal of stock
3 Master Data from a storage bin and placing it into a pick-handling unit. Depending on the
packing requirements, the pick HU may be taken to a packing work center
4 Business Process where the products in the pick HU are packed further into other HUs, e.g.,
Description – for shipping.
Inbound Process

5 Business Process The transaction for using the packaging workstation is /SCWM/PACK. After
Description entering the work center on the left side of the work center screen, for example,
for Outbound you can use the the simple drag-and-drop functionality to repack entire handling
units or to pack products into other handling units.
6 Generic Part

7 Appendix The upper-right screen area consists of tab pages. This transaction is designed
for users who physically pack products at work centers in the warehouse.
8 Legal Require- Devices like barcode scanner or keyboards can be used for packing activities.
ments The exact weight can be determined using scales connected to the system.

Packing in the work center offers the following functionality:

• Scanning of
– HU identification
– Product
– Warehouse task
– Storage section
• Creation of handling units
• Repacking of handling units
• Repacking of products
• Post differences
• Changing handling units
• Deconsolidation of handling units

94 / 143
1 Getting Started 5.10.2 Business Monitoring
Entry screen of transaction /SCWM/PACK – Packing Work Center
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
In the work center on the left side, you see the current workload in the work
center.

95 / 143
1 Getting Started 5.10.3 Business Monitoring via SAP Fiori Apps
With release 1809 for packing, the SAP Fiori app Pack Outbound Deliveries
2 Introduction
was introduced:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Also introduced was tracking the packing status in Run Outbound Process:

96 / 143
1 Getting Started 5.11 GOODS ISSUE POSTING AND CREATION OF FINAL DELIVERY
5.11.1 Description
2 Introduction
A goods issue from SAP EWM is a physical departure of products from the
3 Master Data warehouse. With a goods issue posting, the stock in the warehouse will be
reduced. The goods issue posting can be used to indicate goods deliveries
4 Business Process to customers.
Description –
Inbound Process
The goods issue posting can be done for deliveries (using transaction
5 Business Process /SCWM/PRDO) and vehicles (using transaction /SCWM/TU). Alternatively,
Description goods issue can be posted directly out of the warehouse with transaction
for Outbound /SCWM/ADGI (post unplanned goods issue)

6 Generic Part
The outbound delivery order can also be used to trigger the goods issue
7 Appendix posting and creation of the final delivery.

8 Legal Require- After goods issue has been posted (final), outbound delivery is created and
ments can be selected with the highlighted button in transaction /SCWM/PRDO:

Transaction /SCWM/FD – final delivery – accessed via /SCWM/PRDO:

97 / 143
1 Getting Started From the outbound delivery order, the outbound delivery (OD) document is
created. The outbound delivery document represents the goods to be delivered
2 Introduction
together to a goods recipient. The outbound delivery is used as the basis for
3 Master Data printing the delivery note or for sending a shipping notification. The following
actions using this document can be executed:
4 Business Process • Posting a goods movement
Description – • Canceling a goods movement
Inbound Process
• Setting the status “Leave Yard”
5 Business Process
Description For export-related goods issues, the outbound delivery might be created
for Outbound before the goods issue (GI) posting in SAP EWM. In other cases, the outbound
delivery will automatically be created with the GI posting for the outbound
6 Generic Part
delivery order in SAP EWM.
7 Appendix
Posting goods issue can be done at different points during the loading process,
8 Legal Require- as well as on different levels of inventory: for deliveries, transportation units,
ments doors, or vehicles. Alternatively, the goods issue can be posted directly on the
handling-unit level.

It’s also possible to post and reverse GI using the SAP Fiori app Run Outbound
Process.

98 / 143
1 Getting Started 5.12 POSTING GOODS ISSUE IN ERP
After posting goods issue in SAP EWM, an automatic message is sent back to
2 Introduction
the SAP S/4HANA system. The GI posting is the process step that will reduce
3 Master Data the stock in the warehouse, while triggering the creation of material and goods
movement documents in the connected SAP S/4HANA system. After this step,
4 Business Process invoicing is possible.
Description –
Inbound Process
5.12.1 Business Monitoring
5 Business Process When goods issue is posted in the SAP EWM application, transaction
Description /SCWM/PRDO can be used to check the goods issue status of a delivery.
for Outbound Status of the field “Goods Issue” shows “Completed”:

6 Generic Part

7 Appendix

8 Legal Require-
ments

During the GI posting in SAP EWM, a message is sent to the corresponding

SAP ERP application via qRFC interface. This is triggered by a PPF action
/SCWM/MSG_FDO_SEND, which can be found in the SAP EWM outbound
delivery:

99 / 143
1 Getting Started As well as for the final delivery:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

In the SAP ERP application, an entry in the DLW queue for the document
is created.

100 / 143
1 Getting Started This queue will be processed in the SAP ERP application by the function
module BAPI_OUTB_DELIVERY_CONFIRM_DEC. During execution of the
2 Introduction
qRFC, goods issue posting is performed and the status of the outbound
3 Master Data delivery is updated in the SAP ERP application.

4 Business Process 5.12.2 Monitoring via SAP Fiori Apps

Description – See also Chapter 5.4.3 Run Outbound Process. It’s possible to post goods
Inbound Process
issue (PGI) and reverse PGI in this SAP Fiori app.
5 Business Process
Description 5.13 RFC (REMOTE FUNCTION CALL)
for Outbound Communication from the SAP EWM application to the SAP ERP application
and the other way around uses defined interfaces and enables distribution,
6 Generic Part
changes to, and confirmation of delivery-relevant data. The communication
7 Appendix is asynchronous and uses queued Remote Function Call (qRFC) technology.
This technology guarantees serialization of the messages.
8 Legal Require-
ments 5.14 COMMUNICATION BETWEEN SAP EWM AND NON-SAP SYSTEMS
For communication with non-SAP systems, SAP provides different IDocs:
• /SCWM/WMBBIN – Block storage bins
• /SCWM/WMCATO – Cancellation/cancellation request for transfer order
• /SCWM/WMPIHU – Create and distribute pick-HU
• /SCWM/WMRREF – Release reference number
• /SCWM/WMSUMO – Move handling unit
• /SCWM/WMTOCO – Confirm warehouse order/warehouse task
• /SCWM/WMTORD – Create warehouse order

Overview of IDoc message types to be issued from SAP EWM:

101 / 143
 6 Generic Part
1 Getting Started The generic part of this business process management best practice provides
information regarding common monitoring activities that are not specific to
2 Introduction
special business process steps. The following topics are covered:
3 Master Data • Performance monitoring
• Batch jobs
4 Business Process • General monitoring guidelines for systems running on SAP S/4HANA
Description –
Inbound Process
These sections are referenced in the corresponding business process steps
5 Business Process of the scenario specific parts above.
Description
for Outbound 6.1 INTERFACE MONITORING
With the first release of SAP EWM, new interfaces were created, and existing
6 Generic Part
ones were reused. To help you monitor these interfaces, the following chapters
7 Appendix provide an overview:

8 Legal Require- 6.1.1 qRFC Monitoring

ments As part of SAP software components, qRFCs and intermediate documents
(IDocs) also contribute to the system load. The general monitoring tools are
important to monitor the overall system response time. such as the following:
• ST03N – Workload and performance statistics
• ST02 – Tune summary/setups/tune buffers
• ST06 – Operating system monitor
• SM21 – Display system logs
• ST22 – ABAP® runtime error

However, since these tools are quite familiar, this chapter is dedicated to
discussing only tools specific to monitoring IDocs and CIF, focusing on the
tools related to queue monitoring.

102 / 143
1 Getting Started For IDocs, you can find the monitoring tools here:

2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

For further help regarding IDoc monitoring and performance, please visit
IDoc Monitoring. In case of problems with IDoc performance, please refer to:
• SAP Note 1333417 – Performance problems when processing IDocs
immediately
• SAP Note 3090953 – Enhanced analysis option for IDoc inbound processing

The following tools are not only for monitoring, but also enable you to administer
qRFC/tRFC, such as to restart local unit of work (LUWs) in Status SYSFAIL,
delete them from the queue, and/or to reactivate a blocked queue. Those
transactions are:
• SMQ1 – qRFC monitor for the outbound queue. This transaction is to moni-
tor the status of the LUWs in the outbound queue. This allows you to display,
activate, debug, or delete queues.
• SMQ2 – qRFC monitor for the inbound queue. This transaction is to monitor
the status of the LUWs in the inbound queue. This allows you to display,
activate, debug, or delete queues.
• SMQ3 – qRFC monitor for saved queues (inbound). This transaction is
to temporarily store LUWs. This allows you to display, delete, and restore
queues.
• SMQR – Inbound queue scheduler. This transaction is to administer
inbound queue such as register, deregister, and exclude queues.
• SMQS – Outbound queue scheduler. This transaction is to administer
outbound queue such as register, deregister, and exclude destinations.

103 / 143
1 Getting Started Remark: Before saving and deleting queues, please refer to
SAP Note 2375304 – Deleted queues from SMQ2
2 Introduction

3 Master Data 6.1.1.1 SMQ1-qRFC monitor (outbound queue)

Transaction SMQ1 – qRFC monitor can be used to monitor outbound qRFC.
4 Business Process The queues will be shown depending on the selection criteria on the selection
Description – screen.
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
Outbound queue menu options

Under qRFC menu, the following options are available:

• Trace
In addition to the existing RFC traces, a trace can be activated specifically for
the qRFC. This trace displays qRFC LUW information, such as TID (transac-
tion ID), function name, queue name, time of transfer, and time of execution.
If required, the trace flag in SM59 must be activated for further analysis. For
each LUW processed, several entries are written for each TID. For example,
for a successfully processed TID, the following five entries are written in the
trace:
– Recorded
– Sending
– Running
– Finish
– Confirmed

104 / 143
1 Getting Started • Log
In the log, TIDs are listed only for problems that have occurred during
2 Introduction
transfer or processing. Activation of the log can occur for each queue
3 Master Data individually or generically.
• Reorganize
4 Business Process Delete all registered entries of qRFC administration (log, trace, events).
Description – • Version
Inbound Process
Displays the current qRFC version.
5 Business Process
Description Within the “Information” menu, the following options are available:
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Outbound queue status

If an error is shown in the status field, more detailed information can
be displayed when double-clicking on the status. Please also refer to
SAP Note 378903 – Queue status in SMQ1, SMQ2, and table ARFCRSTATE.

READY
The queue is ready for transmission. This status should only be temporary.
However, in the following case, this status can also be a permanent status:
a queue was locked manually via transaction SMQ1 or via a program and
then unlocked without being activated at the same time. This queue must
be activated explicitly.

RUNNING
The first LUW of this queue is currently being processed. If a queue in this
STATUS hangs for more than 30 minutes, this may mean that the work pro-
cess responsible for sending this LUW has terminated. In this case, the queue
can be activated again. Note that activating a queue in status RUNNING may
cause an LUW to be executed several times if this LUW is processed in the
target system at that time. We therefore recommend a waiting time of at
least 30 minutes before activating the queue again.

105 / 143
1 Getting Started EXECUTED
The first LUW of this queue is processed. The system waits for a qRFC-internal
2 Introduction
confirmation from the target system before further LUWs are processed. If a
3 Master Data queue in this STATUS hangs for more than 30 minutes, this might mean that
the work process responsible for sending this LUW has terminated. In contrast
4 Business Process to status RUNNING, this current LUW has definitely been executed success-
Description – fully. The queue can be activated again without problems. The qRFC Manager
Inbound Process
will automatically delete the LUW already executed and send the next LUW.
5 Business Process
Description SYSLOAD
for Outbound At the time of the qRFC call, no DIALOG work processes were free in the send-
ing system for sending the LUW asynchronously. A batch job for subsequent
6 Generic Part
sending has already been scheduled.
7 Appendix
SYSFAIL
8 Legal Require- A serious error occurred in the target system while the first LUW of this queue
ments was executed. The execution was interrupted. When double-clicking on this
status, the system displays an error text. Additional information on this error
can be found in the corresponding short dump in the target system (ST22). No
batch job is scheduled for a repetition, and the queue is no longer processed.
To solve the problem, information from the affected application is required.
Refer to SAP Note 335162 – Error “connection closed” in tRFC/qRFC monitors
for the special error text “connection closed.”

CPICERR
During transmission or processing of the first LUW in the target system, a net-
work or communication error occurred. When double-clicking on this status,
the system displays an error text. Additional information on this error can be
found in the syslog (SM21), the trace files dev_rd or dev_rfc*. Depending on the
definition in transaction SM59 for the destination used, a batch job is sched-
uled for subsequent sending. Status CPICERR may also exist in the following
cases although no communication error occurred: A qRFC application finds
out that a LUW cannot be processed further due to a temporary error in the
application and therefore calls the RESTART_OF_BACKGROUNDTASK function
module. This prompts the qRFC Manager to cancel the execution of this LUW
and to repeat this LUW later in accordance with the specification in transaction
SM59. In this case, qRFC simulates a communication error with the text
“Command to tRFC/qRFC: Execute LUW once again.” If this error occurs often,
contact the corresponding application team.

106 / 143
1 Getting Started STOP
On this queue or a generic queue (for example BASIS_*), a lock was set explicitly
2 Introduction
(SMQ1 or programs). Note that the qRFC never locks a queue in its processing.
3 Master Data After having informed the corresponding application team, this queue can be
unlocked and activated via transaction SMQ1.
4 Business Process
Description – WAITSTOP
Inbound Process
The first LUW of this queue has dependencies on other queues, and at least
5 Business Process one of these queues is currently still locked.
Description
for Outbound WAITING
The first LUW of this queue has dependencies on other queues, and at least
6 Generic Part
one of these queues contains other LUWs with higher priorities.
7 Appendix
NOSEND
8 Legal Require- LUWs of this queue are never sent but retrieved by a special application. These
ments queues are only used internally at SAP (SAP Business Warehouse or SAP CRM
during communication with mobile clients). Even if an LUW was read by the
corresponding application (SAP BW, SAP CRM), this status does not change.
This LUW is only deleted from the queue if this application confirms collection
(collective confirmation possible). Under no circumstances should this status
be reset using transaction SMQ1 and the queue activated.

NOSENDS
During the qRFC call, the application determines that the current LUW is not
sent immediately. This is used to debug the execution of an LUW via transac-
tion SMQ1. Contact the corresponding qRFC application to clarify this status
since this is either a programming or configuration problem.

WAITUPDA
This status is set if qRFC is called within a transaction that also contains one or
more update functions. As a result of this status, the LUW and thus the queue
is blocked until the update has been completed successfully. If this status
takes longer than a few minutes, check the status of the update or the update
requests using transaction SM13. After a successful retroactive update, the
blocked LUW is sent automatically. The LUWs can also be restarted manually
in the WAITUPDA status without a successful retroactive update (via transac-
tion SMQ1, reset status, activate queue). This WAITUPDA problem may be
avoided as follows: If both qRFC calls and update calls occur within a transac-
tion, qRFC must be executed exclusively within the update. In this case, the
qRFC LUW is only created after the update has been completed successfully.

107 / 143
1 Getting Started RETRY/ARETRY
During LUW execution, the application has diagnosed a temporary problem
2 Introduction
and has prompted the qRFC manager in the sending system via a specific
3 Master Data qRFC call to schedule a batch job for a repetition on the basis of the definition
in transaction SM59 (Menu: Destination > TRFC Options)
4 Business Process
Description – ANORETRY
Inbound Process
During the LUW execution, the application has found a serious error and
5 Business Process prompted the qRFC manager via a specific qRFC call to cancel processing
Description of this LUW. Information from the affected application is required to solve
for Outbound the problem.

6 Generic Part
MODIFY
7 Appendix Processing this queue is locked temporarily because the LUW data is being
modified.
8 Legal Require-
ments Remark: Report RSQOWKEX can reset the status of all queues (CPICERR,
RETRY, SYSFAIL) and restarts the outbound scheduler. This report can be used
in exceptional cases; do not schedule this report on regular basis. Investigate
the error before restarting the queue.

Outbound queue LUW DETAIL

The detailed status text provides further details on issues occurred during
qRFC processing. In case of error, the status field of the first LUW will be
marked in red, and a status text provides further details on the issue occurred
during processing. The left side of the screen is shown below:

in orange box: Debug the logical unit of work (LUW).

The right side of the screen is depicted below:

108 / 143
1 Getting Started 6.1.1.2 SMQ2-qRFC Monitor (Inbound Queue)
Inbound queue monitoring screens and menus are similar to the outbound
2 Introduction
queue monitoring tool.
3 Master Data
A hanging queue is defined as a queue:
4 Business Process • Where the first LUW is not processed longer than 30 minutes
Description – • Where a system error occurred (SYSFAIL or CPIC error)
Inbound Process

5 Business Process Inbound queue status

Description If an error is shown in the status field, more detailed information will be
for Outbound displayed when double-clicking on the status. The possible statuses are
the same as for outbound queues.
6 Generic Part

7 Appendix 6.1.1.3 SMQ3 qRFC Monitor (Saved Inbound Queue)

SMQ3 contains saved queues from the inbound queue, e.g., for late execution.
8 Legal Require-
ments 6.1.1.4 QIN Scheduler (SMQR)
This transaction is for displaying the state of the QIN-Scheduler and for
registering or deregistering a queue. You can see the scheduler status at
the top of the screen.

QIN scheduler screen:

109 / 143
1 Getting Started By double-clicking on the corresponding line, you can see the first sub-screen
of SMQ2 for more details about the inbound queue content.
2 Introduction

3 Master Data QIN scheduler status

These statuses are possible.
4 Business Process
Description – INACTIVE
Inbound Process
The QIN scheduler is not active.
5 Business Process
Description BATCHJOB SCHEDULED
for Outbound The QIN scheduler has scheduled a batch job.

6 Generic Part
STARTING
7 Appendix The QIN scheduler is currently in the START phase.

8 Legal Require- ACTIVE

ments The QIN scheduler is active.

WAITING
The QIN scheduler waits for free DIALOG work process.

SYSFAIL
A serious error occurred in the current operations of the QIN Scheduler.
Double-clicking the status displays the respective error text. Other analyses
of the syslog (SM21) or development traces (dev_w*, dev_rfc* and dev_rd)
may be required for the fault determination.

CPICERR
A communication error occurred in the current operations of the QIN Scheduler.
Double-clicking the statuses displays the respective error text. Other analyses
of the syslog (SM21) or development traces (dev_rd, dev_rfc* and dev_w*)
may be required for the fault determination.

110 / 143
1 Getting Started QIN scheduler menu options
Deregistration of a queue
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Press button “Deregistration“ and enter the queue name to be deregistered.

After that, the queue or the filter with Wildcards appears in the list and “Type”
has changed from “R” (registered) to “U” (unregistered).

111 / 143
1 Getting Started To process unregistered queues, the queue must be registered again. Mark
the line and press the button “Registration.” For further information about
2 Introduction
SMQR, please refer to SAP Note 1579728 – SMQR – Inbound queue scheduler
3 Master Data settings – explained.

4 Business Process 6.1.1.5 SMQS – Outbound Queue Scheduler

Description – This transaction is for displaying the state of the QOUT-Scheduler and for
Inbound Process
registering or deregistering queue. The scheduler status can be seen at the
5 Business Process top of the screen.
Description
for Outbound Remark: To distribute resources on the receiving system, a logon group should
be defined, using transaction SMLG – CCMS: Maintain Logon Groups. In this
6 Generic Part
way, a specific server can be excluded from the RFC processing (e.g., the
7 Appendix database server) to avoid overload.

8 Legal Require- In regard to parametrization of maximum connections for better performance,

ments refer to SAP Note 3299538 – How to set the Max.Conn. value in SMQS

QOUT Scheduler Screen

Scheduler status
To see the current status, refresh the screen.

Last update
This shows the time and date of the last activation of the scheduler.

112 / 143
1 Getting Started Name of AS group
This shows the name of the used RFC server group. The group name
2 Introduction
“DEFAULT” is standard and uses all available application servers in the system.
3 Master Data The RFC server group can be changed via menu “Edit” > “Change AS group.”
Please be sure that the RFC group used is available in RZ12. It is not necessary
4 Business Process to maintain AS group “DEFAULT” in RZ12.
Description –
Inbound Process
Number of Entries Displayed
5 Business Process This shows the number of the registered destinations.
Description
for Outbound QOUT scheduler status
These statuses are possible.
6 Generic Part

7 Appendix NACTIVE
The QOUT scheduler is not active.
8 Legal Require-
ments STARTING
The QOUT scheduler is currently in the START phase.

ACTIVE
The QOUT scheduler is active.

WAITING
The QOUT scheduler waits for free DIALOG work process.

SYSFAIL
A serious error occurred in the current operation of the QOUT scheduler.
Double-clicking the status displays the respective error text. Other analyses
of the syslog (SM21) or development traces (dev_w*, dev_rfc* and dev_rd)
may be required for the fault determination. After solving the problem, the
QOUT scheduler will not automatically restart the LUW of the registered
destination. Queue status (SYSFAIL) of dedicated queues must be reset
manually. This can be done in transaction SMQ1.

CPICFAIL
A communication error occurred in the current operations of the QOUT
scheduler. Double-clicking the statuses displays the respective error text.
Other analyses of the syslog (SM21) or development traces (dev_rd,
dev_rfc* and dev_w*) may be required for the fault determination.

For performance problems in regard to RFC, please refer to SAP Note 2183108
t/qRFC processing: general performance verifications.

113 / 143
1 Getting Started QOUT scheduler menu options
In transaction SMQS, the following menu options are available:
2 Introduction

3 Master Data Registration table

Reorganize: Deletes all registrations. This does not affect the content
4 Business Process of the tRFC/qRFC.
Description –
Inbound Process
Edit: The following menu options are available:
5 Business Process • Deregister
Description Deregister the selected destination. The registered destination is not pro-
for Outbound cessed by the QOUT scheduler. The collected LUWs remain in the queue.
This enables you to collect single LUWs in the queue and analyze them
6 Generic Part
(for example, debugging a single LUW).
7 Appendix • Exclude
A destination can be excluded from QOUT scheduler processing, and
8 Legal Require- hence is processed by the tRFC manager at the time of the “Commit Work”
ments command. The processing for LUWs of this destination then occurs on
any application server of the system.
• Delete
Delete the selected registration entry. The trash can icon on the top left
corner can also be used for the same purpose. The registered destination
is deleted. If a tRFC or qRFC still runs using this destination, the system
recreates the destination. Prerequisite for this is that the logon data must
be complete for the destination in SM59: language, client, user, and pass-
word must be entered. The target system must not be NONE or Space.
• Change AS group
The scheduler uses a server group for processing LUWs. The application
server group used is displayed in the third column. If the name of the appli­
cation server group has been changed (#DEFAULT), ensure that the server
group exists in transaction RZ12.
• Activate Scheduler
Start the scheduler. The last start time is displayed in the second line in the
top left corner. The status in the top line changes throughout the runtime.
The status is now “Active.”
• Change view
Displays the status of the scheduler.

Under menu Goto, the following options are available:

• QRFC administration
Navigate to the menu for starting qRFC events.
• QRFC resources
Jump to the information of resources availability for the corresponding
system.

114 / 143
1 Getting Started 6.1.1.6 Debugging qRFC Queues
For qRFC debugging, the following profile parameters have to be maintained
2 Introduction
in the corresponding system (SAP ERP or SAP EWM) under „User Profile“ >
3 Master Data “Own Data“:

4 Business Process SAP EWM

Description – Parameter: /SCWM/IF_DEBUG_QRFC = X (Debugging for qRFC; X = stop queue)
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

SAP ERP
Parameter: /SPE/IF_DEBUG_QRFC = X (Debugging for qRFC; X = stop queue)

Hint: If the flag SPE/IF_DEBUG_QRFC = X maintained in the SAP ERP appli­

cation, then the qRFC remains unprocessed in the SAP EWM application. The
other way around is if the parameter /SCWM/IF_DEBUG_QRFC is maintained
in the SAP EWM application; then the qRFC will be on hold in the inbound
queue of SAP ERP.

115 / 143
1 Getting Started 6.2 HOUSEKEEPING JOBS
Certain jobs must run periodically in a production SAP EWM application –
2 Introduction
for example, deleting obsolete jobs or spool objects. If these periodic jobs
3 Master Data do not run, system performance may get worse over time. Unfortunately,
there is currently no easy-to-use support for such jobs in Basis Customizing.
4 Business Process Therefore, the jobs must be scheduled manually. For a complete and up-to-
Description – date reference of recommended periodic jobs, see SAP Note 2190119 – Back-
Inbound Process
ground information about SAP S/4HANA technical job repository > standard
5 Business Process jobs, reorganization jobs. Note that we recommend daily monitoring of the job
Description log using transaction SM37, where you can find notifications about updates.
for Outbound
As these jobs are listed in detail in the SAP S/4HANA Operations Guide, please
6 Generic Part
refer to this guide. You will find the best practices for SAP EWM housekeeping
7 Appendix on pages 55 to 61.

8 Legal Require- To monitor different kinds of jobs, you can use either transaction SM37 and
ments choose a selection that suits your needs. Or you can look into Job automation
and monitoring, which comes with the SAP Cloud ALM tool.

Simple job selection with SM37

116 / 143
1 Getting Started Extended job selection with SM37 (with further subnodes include status,
step, active, period, and job type):
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

SAP Cloud ALM has functionality called “Job and Automation Monitoring.”
This dashboard is more of a monitoring tool that gives users an overview about
the Jobs running in their system(s).

117 / 143
1 Getting Started Further information and analysis are available in “Job and Automation
Monitoring”:
2 Introduction

3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments
6.2.1 Error-Handling Procedures for Batch Jobs
If one of the scheduled jobs fails, a necessary job is not scheduled, or
even if a scheduled job has finished, check for the current job status (refer
to SAP S/4HANA documentation CD, component BC-CCM, chapter back-
ground processing) and proceed as follows:
• Status scheduled: The job steps have already been defined, but the start
condition has not yet been defined. Contact the program scheduling man-
agement to clarify when the job will be fully defined.
• Status released: The job has been fully defined including a start condition
and is waiting for the condition to fulfill.
• Status ready: The start condition of a released job has been met. A job
scheduler has put the job in line to wait for an available background work
process.
• Status active: The job is currently running and cannot be modified or
deleted. Check if the job is within the given time frame, depending on the
data volume to be processed. Check for dependencies on other jobs. If the
job exceeded the given time frame, contact the software monitoring team.
• Status finished: All steps that make up this job have completed successfully.
Program scheduling management should check whether the job ran in the
given time frame, and the software monitoring team and/ or application
support should check the respective job results (such as spool output lists,
message logs, updates, etc.).
• Status cancelled: The job has terminated abnormally, which can happen
in two ways. If an administrator intentionally cancelled the job, clarify the
reason and whether (and if, when) the job must be rerun.

118 / 143
1 Getting Started If a program in a job step produced an error such as issuing an “E” or “A” error
message, contact the software monitoring team and investigate why the error
2 Introduction
occurred. In case of an SAP standard program, search for appropriate mes-
3 Master Data sages in SAP ONE Support Launchpad and open a customer message if the
problem cannot be solved.
4 Business Process
Description – 6.2.2 Job Restartability
Inbound Process
In case of the cancellation of a background job, possible succeeding jobs or
5 Business Process dependencies on other jobs must be considered when restarting the aborted
Description job. The start of succeeding jobs might be delayed due to the restart of the
for Outbound aborted job.

6 Generic Part
6.3 ARCHIVING AND ARCHIVING JOBS
7 Appendix SAP EWM uses the standard tools for archiving and does not require
component-specific tools.
8 Legal Require-
ments Batch programs have been provided in SAP EWM to archive records, reorga-
nize tables, and delete old data records that are no longer needed in the sys-
tem. These programs can be used to archive the database and to hold data
records accessible for future reference.

The recommendation is not to start the archiving directly in the online mode,
but instead with the archiving management transaction in the background.

To archive and delete from the database, use two different reports for a ware-
house task, for example, WME_ARCH_TO_WRITE and WME_ARCH_TO_
DELETE. The write programs create the archive and then start the delete pro-
grams as a separate job for each archive. The delete programs can delete only
data records that they have previously read in the archives.

The size of the archive files can be specified in a way to improve the perfor-
mance of large data quantities because SAP EWM processes write and delete
programs in parallel.

You can find further information on archiving and archiving objects in SAP EWM.

6.3.1 General Prerequisite

The documents to be archived must have the status “Completed” and the
retention time (residence time) of the documents must have expired.

The residence time is set in customizing in: SAP Extended Warehouse Manage-
ment > Goods Receipt Process > Inbound Delivery > Define Document Types
for Inbound Delivery Process.

119 / 143
1 Getting Started The same parameter can also be set for Outbound Deliveries: SAP Extended
Warehouse Management > Goods Issue Process > Outbound Delivery > Define
2 Introduction
Document Types for Outbound Delivery Process.
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

120 / 143
1 Getting Started Before starting the archiving, the status of the related delivery documents
should be changed from “completed” to “to be archived.” This can be performed
2 Introduction
with the archiving preprocessor report /SCDL/BO_ARCHIVE:
3 Master Data

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

The write program runtime depends on the number of archived data records
as well as on the general system load and system performance.

121 / 143
1 Getting Started 6.3.2 Reading Archive Files
To read data records that have already been archived, either use the SAP archive
2 Introduction
infosystem (transaction SARI) or the read reports from the table. The reports
3 Master Data can be started for reading archiving data from the archive management, as
well. It’s also possible to use advanced search, for example, in “Inbound and
4 Business Process Outbound Deliveries”:
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

6.3.3 Reorganization
The report /SCWM/R_REORG_HU_WO_PRINT can be used to delete persistent
print data records and PPF data records from handling units and warehouse
orders that are no longer needed in SAP EWM. This report is also further
explained in the SAP S/4HANA Operations Guide.

6.3.4 Activities
• To use write programs, the SAP system must be set up accordingly.
For more information, see the blog post: SAP Archiving Step by Step Guide
for Beginners and adapt the steps according to the SAP EWM objects.
• Execute archiving of data records.

122 / 143
1 Getting Started Objects in SAP EWM such as warehouse task, warehouse order, wave, and
resource status log can be archived. To do so, you can use the following reports
2 Introduction
and find further details in the SAP EWM application operations guide:
3 Master Data
Application Document Archiving Report Table
4 Business Process Component Category Object Name
Description – Delivery Internal warehouse DLV_INB /SCDL/ /SCDL/DB_PROCH_I
Inbound Process Processing request (inbound DLV_INB_ARCH_DELETE /SCDL/DB_PROCI_I
delivery) /SCDL/ /SCDL/DB_BPLOC
5 Business Process DLV_INB_ARCH_WRITE
/SCDL/DB_DATE
Description /SCDL/
/SCDL/DB_STATUS
for Outbound DLV_INB_ACRH_READ
/SCDL/DB_REFDOC
6 Generic Part /SCDL/DB_ADDMEAS
/SCDL/DB_GROUP
7 Appendix /SCDL/DB_TRANS
/SCDL/DB_EXTNO
8 Legal Require-
/SCDL/DB_PRCODES
ments
/SCWM/DB_ITEM
/SCWM/DLV_SERI
• Internal warehouse DLV_OUT /SCDL/ /SCDL/DB_KEYMAP
request DLV_OUT_ARCH_DELETE /SCDL/DB_BPLOC
• Outbound delivery /SCDL/ /SCDL/DB_DATE
• Outbound delivery DLV_OUT_ARCH_WRITE
order /SCDL/DB_STATUS
/SCDL/
• Posting change /SCDL/DB_REFDOC
DLV_OUT_ACRH_READ
• Stock transfer /SCDL/DB_ADDMEAS
/SCDL/DB_GROUP
/SCDL/DB_TRANS
/SCDL/DB_REQH
/SCDL/DB_REQI
/SCDL/DB_EXTNO
/SCDL/DB_HU
/SCDL/DB_HUITEM
/SCDL/DB_HUPROD
/SCDL/DB_HUREFHU
/SCDL/DB_HUIDENT
/SCDL/DB_HUEPC
/SCDL/DB_ACC
/SCWM/DB_REQI_TO
/SCWM/DLV_SERI

123 / 143
1 Getting Started Warehouse
Logistic
Warehouse tasks and WME_TO
goods movement
WME_ARCH_TO_WRITE /SCWM/ORDIM_C
WME_ARCH_TO_DELETE /SCWM/ORDIM_C
Processing documents
2 Introduction WME_ARCH_TO_READ /SCWM/ORDIM_CS
(from SCM 5.1)
3 Master Data /SCWM/ORDIM_E
/SCWM/ORDIM_HS
4 Business Process (from SCM 5.1)
Description – /SCWM/ORDIM_LS
Inbound Process (from SCM 5.1)
/SCWM/ORDIM_H
5 Business Process
/SCWM/ORDIM_L
Description
/SCWM/DB_ITEMWT
for Outbound
(only delete)

6 Generic Part Warehouse orders WME_WO WME_ARCH_WO_WRITE /SCWM/WHO

WME_ARCH_WO_DELETE /SCWM/WO_PPF
7 Appendix WME_ARCH_WO_READ
Waves WME_ WME_ARCH_WAVE_ /SCW/WAVEHDR
8 Legal Require-
WAVE DELETE /SCWM/WAVEITM
ments
WME_ARCH_WAVE_WRITE
WME_ARCH_WAVE_READ
Telegram flows WME_ WME_ARCH_MFS_DELETE /SCWM/
MFS WME_ARCH_MFS_WRITE MFSTELELOG
WME_ARCH_MFS_READ
Relevant resource WME_ WME_ARCH_RSRC_ /SCW/USR_ST_LOG
data RSRC DELETE
WME_ARCH_RSRC_WRITE
WME_ARCH_RSRC_READ
Value-added- WME_VAS WME_ARCH_VAS_DELETE Usage of ODM (Order
services order WME_ARCH_VAS_WRITE Document Manage-
(VAS order) ment > dynamic data-
WME_ARCH_VAS_READ
base table creation)
/1OM/
VASOVASxCLIENT
For example:
/1OM/VASOVASH500
/1OM/VASOVASA500
/1OM/VASOVASI500
/1OM/VASOVASP500

124 / 143
1 Getting Started Warehouse
Logistic
Handling units WME_HU WME_ARCH_HU_WRITE EWM 5.0:
WME_ARCH_HU_DELETE /scwm/huhdr_log
Processing
2 Introduction WME_ARCH_HU_READ /scwm/hu_ident
/scwm/quan
3 Master Data /scwm/huref
/scwm/hustobj
4 Business Process
/scwm/husstat
Description –
Inbound Process From EWM 5.1:
/scwm/gmhuhdr
5 Business Process /scwm/gmhuref
Description /scwm/gmhuident
for Outbound /scwm/gmhustobj
/scwm/gmhustat
6 Generic Part
/scwm/gmhuitm
7 Appendix /scwm/gmhuitmsn
QIE (quality inspec- QIE_INSP QIE_INSP_ARC_CHECK
8 Legal Require- tion documents) QIE_INSP_ARC_DELETE
ments
QIE_INSP_ARC_WRITE
Physical inventory LIME_PI /LIME/PI_ARCH_DL
documents /LIME/PI_ARCH_WR
LIME log entries LIME_NLOG
(goods movement
and confirmed
warehouse tasks)
periodicity analogous
to WME_TO
Site Logistic Door activities WME_ WME_ARCH_DOOR_ /SCWM/DOOR_SRACT
Processing DOOR MARK /SCWM/TDOOR
WME_ARCH_DOOR_
WRITE
WME_ARCH_DOOR_
DELETE
WME_ARCH_DOOR_READ
Vehicle activities WME_VEH WME_ARCH_VEH_DELETE /SCWM/VEHICLE
WME_ARCH_VEH_MARK /SCWM/VEH_IDENT
WME_ARCH_VEH_MARK_ /SCWM/VEH_SR_ACT
AND_WRITE /SCWM/VEH_STATUS
WME_ARCH_VEH_READ
WME_ARCH_VEH_WRITE
Transportation WME_TU WME_ARCH_TU_DELETE /SCWM/TU_SR_ACT
unit activities WME_ARCH_TU_MARK_ /SCWM/TUNIT
AND_WRITE /SCWM/TU_STATUS
WME_ARCH_TU_READ /SCWM/TU_IDENT
WME_ARCH_TU_WRITE /SCWM/TUNIT_SEAL
WME_ARCH_TU_MARK /SCWM/TU_DOOR
/SCWM/TU_VEH
/SCWM/TU_DLV

125 / 143
1 Getting Started Labor
Manage-
Indirect labor tasks WME_ILT WME_ARCH_ILT_DELETE Usage of ODM (Order
Document Manage-
WME_ARCH_ILT_READ
ment ment > dynamic data-
2 Introduction WME_ARCH_ILT_WRITE
base table creation)

3 Master Data /1OM/ILT_ILT_CLIENT

For example:
4 Business Process /1OM/ILT_ILT_500
Description – Executed workloads WME_EWL /SCWM/
Inbound Process EWL_ARCH_DELETE
/SCWM/
5 Business Process EWL_ARCH_WRITE
Description Employee WME_EPD /SCWM/
for Outbound performance EPD_ARCH_DELETE
document /SCWM/
6 Generic Part EPD_ARCH_WRITE
Business partners CA_BUPA
7 Appendix
(processors) – only
if created originally
8 Legal Require- in SAP EWM
ments
Freight Shipments TM_SHP /SCTM/ CDCLS
Order R_SHP_ARCHIVE_DELETE CDHDR
Processing /SCTM/ CDPOS_STR
R_SHP_ARCHIVE_RELOAD
CDPOS_UID
/SCTM/
STXB
R_SHP_ARCHIVE_WRITE
STXH
STXL
Also the following
tables are used
(***: client number
of the system):
/1OM/TMSH1NOT***
/1OM/TMSH2NOT***
/1OM/TMSHHSTT***
/1OM/TMSHTDAI***
/1OM/TMSHTDAT***
/1OM/TMSHTEQU***
/1OM/TMSHTGRO***
/1OM/TMSHTHRF***
/1OM/TMSHTIRF***
/1OM/TMSHTPAC***
/1OM/TMSHTPLH***
/1OM/TMSHTPLI***
/1OM/TMSHTPRO***
/1OM/TMSHTSHD***
/1OM/TMSHTSIT***
/1OM/TMSHTUOM***

126 / 143
1 Getting Started Freight
Order
Freight order
documents
TM_FRD /SCTM/ CDCLS
R_FRD_ARCHIVE_DELETE CDHDR
Processing
2 Introduction /SCTM/ CDPOS_STR
R_FRD_ARCHIVE_RELOAD
CDPOS_UID
3 Master Data /SCTM/
STXB
R_FRD_ARCHIVE_WRITE
STXH
4 Business Process
STXL
Description –
Inbound Process Also the following
tables are used
5 Business Process (the last three digits
are the client number
Description
of the system – in this
for Outbound case, 401):
/1OM/TMFR1NOT401
6 Generic Part
/1OM/TMFRHSTT401
7 Appendix /1OM/TMFRTDAT401
/1OM/TMFRTEQU401
8 Legal Require- /1OM/TMFRTHRF401
ments /1OM/TMFRTIRF401
/1OM/TMFRTMFH401
/1OM/TMFRTMFP401
/1OM/TMFRTPLH401
/1OM/TMFRTSTP401

6.4 PERFORMANCE MONITORING

This chapter provides a description of a general procedure for performance
monitoring of systems running on SAP S/4HANA, including embedded and
decentral instances of the SAP EWM application. The different transactions
that are mentioned in the procedure are described in detail below. Please
keep in mind that this is general information. For specific recommendations
for a scenario (field sales or e-commerce, for example), please check the
corresponding chapters above.

Please also consider the training ADM415 – Performance Analysis. This course
covers topics like workload monitor, statistical records, expensive SQL statements,
memory management, database monitor, and buffer analysis, among others.

6.4.1 General Information

As part of the daily monitoring activities of a system running on SAP S/4HANA,
you should not only look after system availability, system resource consumption,
and middleware queues (among others), but also system performance. There
are several transactions available that can be used to monitor the average
performance of the system and analyze the cause of bad performance. Bad
performance of a system is generally equal to extremely high response times.

127 / 143
1 Getting Started This may be related to lengthy transactions steps (dialog steps),
background jobs running too long, and so on.
2 Introduction

3 Master Data The response time of a transaction step is the difference in time between the
point when the request arrives in the system and the point when it completes
4 Business Process the processing. In addition to this measurement of time, other different times,
Description – such as waiting times or database times, are still measured in SAP S/4HANA.
Inbound Process
The subtraction of these components from the response time leaves the pro-
5 Business Process cessing time, which cannot be directly measured. ABAP programming code
Description is processed during the processing time.
for Outbound
Definitions of the most important components of the response time:
6 Generic Part
• Time in work process
7 Appendix Time actually spent in the work process (after the dispatcher has found
a free work process)
8 Legal Require- • Wait time
ments The dispatcher is waiting for a free work process (= dispatcher queue).
• CPU time
It is only given as a sum per transaction step in the workload statistics
• DB time
Time for accessing and waiting for the database interface, and therefore
for the underlying database
• Load/generating time
Time for loading/generating screens, ABAP programs, and CUA elements
(not for presentation).
• Roll-in time
Time for rolling in the roll area context of a dialog step
• Enqueue time
Time for setting a logical SAP in queue
• Processing time
This time is calculated: Processing time = Response time - Wait time
- Load/Generating time - DB time - Roll-in time - In queue time

Important: The CPU time should not be added to the above lines, as it is
a total consisting of parts of the times listed above that cannot be calculated.
CPU time is returned by the operating system. The accuracy of the reported
value depends on the timer of the operating system. (Under UNIX, for example,
the timer works with 100 Hz so that the CPU time is reported as a multiple of
10 minutes.) Due to this rough resolution of the CPU time, it is possible that a
slightly longer CPU time is displayed for a dialog step than for the response time.

128 / 143
1 Getting Started The rollout time is not part of the response time, as it only occurs after the
data is transferred to the presentation server. The roll wait time is the time
2 Introduction
during which a work process is waiting for the response of an RFC. The roll
3 Master Data wait time is processed on a client whereas the user context is in the roll area.
Therefore, neither resources are used up nor does the bottleneck occur
4 Business Process here for high roll wait time. High roll wait times occur frequently. This may
Description – be caused by calls of Microsoft Windows or other external applications from
Inbound Process
within the SAP system. Here, the application of the RFC is started. The user
5 Business Process context enters the roll areas, and roll wait time is processed until the applica-
Description tion is exited – that is, the RFC connection is cancelled. Only at this point is
for Outbound the transaction step exited. They also occur when the SAP ERP application
communicates with the front-end controls. While the data on the front end is
6 Generic Part
being processed, the SAP S/4HANA context is rolled out, thus releasing the
7 Appendix work process. This can occur several times during a transaction step. If front-
end Microsoft Office applications such as Microsoft Word are started and
8 Legal Require- closed only after a long time (several minutes), a very long roll wait time also
ments occurs here. Roll wait time is not part of the response time for transaction steps
of task type RFC because no resource use occurs for the application server.

6.4.2 Procedure
The following table provides an overview of the right transactions to be used
for performance monitoring and a first analysis of performance problems.

Transaction Trans. Code Use for … Use When?

Workload monitor ST03N General performance overview Daily (e.g., 3 times)
for the different task types and and upon performance
analysis of system workload problems
Workload/ STAD Detailed performance monitoring Upon performance
statistical records of a short time frame, a single problems
user or a specific transaction
or program
Performance trace ST05 SQL trace of a specific step, Upon performance
short sequence of steps, or problems with high
part of a long running job database times
ABAP runtime SE30 Getting an overview of the Upon performance
analysis duration and performance of problems with high
the source code, from individual CPU times
statements up to complete
transactions

129 / 143
1 Getting Started Key performance indicators
Performance monitoring is most useful if there are previously defined key per-
2 Introduction
formance indicators. Generally speaking, KPIs are quantifiable measurements
3 Master Data that reflect the critical success factors of an organization. In this case we refer
to the system response time for single dialog steps of core business process(es),
4 Business Process for transactions or background jobs. The KPIs should be agreed on by the busi-
Description – ness departments and the systems administrators (happy medium between
Inbound Process
what is needed for business reasons and what is achievable from the system
5 Business Process side). It is also important to use the right granularity for KPIs. There is no need
Description to define a KPI for the response time of every step in the process, but it impor-
for Outbound tant that they are not defined too generally (for example, less than two seconds
for each dialog step), as this might be too tight or too wide for specific needs.
6 Generic Part
Furthermore, performance monitoring should not only refer generally to a task
7 Appendix type, but should go one or two steps further to single transactions or even steps.

8 Legal Require- For example: Company ABC is using the call center scenario for inbound call-
ments ing along with the marketing scenario to create target groups via info set or
queries in the SAP Business Warehouse (SAP BW) application.. As the call
center agents need very good response times for business-partner searches
to answer a call, and the queries for large target groups may take several sec-
onds, we do not recommend that company ABC monitors only the average
response time for dialog transactions. They should rather perform monitoring
on transactions or even on the dialog-step level.

Daily monitoring of system performance and the compliance of the response

times to the established KPIs should be done using the workload monitor
(transaction ST03N). This monitor provides an overview of the response times
and its components (CPU time, DB time, wait time, etc.). In case of performance
problems, use this and other transactions for a deeper analysis:
• If a single user reports problems, use transaction STAD to determine what
part of the response time is particularly high. Compare it with other users to
see if it is an isolated problem. Continue the analysis depending on the result.
• If a single dialog step (one step within a transaction) has a bad performance,
use transaction STAD to determine what part of the response time is particu-
larly high. Continue the analysis depending on the result.
• If there is a general performance problem, use the system monitors to check
resource consumptions. Also use the time profile of transaction ST03N to
check if performance has been decreasing over time or if there are peaks.
Use the user profile for a comparison among different users and user groups,
if a useful naming convention is followed.

130 / 143
1 Getting Started • Get a performance trace (transaction ST05) to analyze performance
problems related to high database times. Get an ABAP runtime analysis
2 Introduction
(transaction SE30) to analyze performance problems related to high
3 Master Data CPU or high processing times.
• If it is not possible to find the cause of the performance problem or you need
4 Business Process further assistance for the analysis, contact the next support level or open an
Description – OSS message on the relevant component in SAP ONE Support Launchpad.
Inbound Process

5 Business Process 6.4.3 Transaction ST03N

Description Transaction ST03N is a very powerful transaction with many functionalities.
for Outbound Therefore, we can mention only a few, concentrating on what can be important
for performance monitoring. The workload monitor is used to analyze statistical
6 Generic Part
data from the SAP kernel. When analyzing the performance of a system, it
7 Appendix should normally start by analyzing the workload overview. For example, totals
for all instances can be displayed and then compared to the performances of
8 Legal Require- individual instances over specific periods of time. The source of possible perfor-
ments mance problems can be quickly determined using the large number of analysis
views and the determined data.

The workload monitor can be used to display the:

• Number of configured instances for each system running on SAP S/4HANA
• Number of users working on the different instances
• Distribution of response times
• Distribution of workload by transaction steps, transactions, packages,
sub applications, and applications
• Transactions with the highest response time and database time
• Memory usage for each transaction or each user per dialog step
• Workload through RFC, listed by transactions, function modules, and
destinations
• Number and volume of spool requests
• Statistics about response time distribution, with or without the GUI time
• Workload and transactions used listed by users, payroll number, and client
• Workload generated by requests from external systems

It is possible to display the data for a particular instance (not only the one the
user is logged onto) or optionally totaled for all instances. Depending on the
user mode, it is possible to choose the time period for which the data should
be displayed between day, week, and month (or determine the length of time
using the “Last Minutes’ Load” function). For most analysis views, all or only
certain task types can be displayed.

131 / 143
1 Getting Started The workload monitor interface is divided into two parts. Use the tree
structures on the left of the screen to make the following settings:
2 Introduction
• Select the user mode
3 Master Data • Select the time period for which the workload should be displayed
• Select various functions and analysis views (data chosen for display)
4 Business Process
Description – The system then displays the result on the right of the screen in a standardized
Inbound Process
ALV grid control.
5 Business Process
Description For general performance monitoring, the following options can be used:
for Outbound • User mode: Choose expert mode
• Workload: Choose the instance and time frame. Select from the last days,
6 Generic Part
weeks, and months. To analyze a particular time within the last 24 hours,
7 Appendix choose “Detailed Analysis,” then “Last Minute’s Load,” and then the needed
time frame on the appropriate instance.
8 Legal Require- • In the first workload overview, the response times and its components
ments for the different task types are available (background, dialog, HTTP, RFC,
update, etc.). Now go to Analysis Views > Transaction Profiles > Standard.
Here a more detailed view is possible, selecting the task type dialog and
the aggregation per transaction, for instance.

The following screenshot shows transaction ST03N using the options:

expert mode, workload for server ldai1qkv_QKV_00, time frame:
February 5, 2023 to February 12, 2023, and standard transaction profile,
showing dialog transactions sorted by average duration descending.

132 / 143
1 Getting Started 6.4.4 Transaction STAD
In the STAD, every step on the SAP S/4HANA application server is recorded.
2 Introduction
The records for all instances of the system are displayed. The business trans-
3 Master Data actions analysis (transaction STAD) calculates the system resource usage
of individual transactions for SAP systems and provides a detailed analysis
4 Business Process of a transaction and the dialog steps. The selection criteria include user,
Description – transaction, program, task type, start date, and start time.
Inbound Process

5 Business Process The analyzed time period can be longer than the interval defined by Read
Description Time, as the system analyzes complete transactions as far as possible.
for Outbound However, it is not always possible to perform a complete analysis for long-
running transactions. As the business transaction analysis is time-consuming,
6 Generic Part
use an interval as short as possible (around 10 minutes).
7 Appendix
The aim of this monitor is to analyze in detail the response times for steps in
8 Legal Require- a process (or transaction). These response times are distributed among their
ments components (DB time, CPU time, wait time, GUI time, etc.).

To use this transaction to analyze the performance of the steps done by

a particular user, proceed as follows:
• Execute the steps once, slowly and sequentially, and record the exact time
at which the steps were executed.
• Go to STAD and display the statistical records related to this single execution
(use the user name and the appropriate time frame to display the correct
records).
• Format the output list (button “Sel. fields”), including the fields “GUI time,”
“CUA reference program,” and “CUA internal command.” The two latter fields
can help to identify the single steps executed.
• Use the time stamps of the statistical records and the execution times
recorded to assign STAD records to the dialog steps that were performed.
• Check which steps have slow response time and determine which part is
most responsible for it (DB, CPU, GUI).
• Depending on the result, proceed with a deeper analysis of the worst steps
using, for example, transaction ST05 (for long DB times), transaction SE30
(for long CPU times), or a network analysis (not described in this document)
in case of high GUI times.
• Depending on what is being analyzed, it might be wise to let the user execute
all steps twice and use the second execution for the analysis. That ensures
that all buffers (e.g., program buffers) are filled.

133 / 143
1 Getting Started This transaction can also be used to see in detail what was going on in the
system during specific hours with bad performance. With this analysis, it is
2 Introduction
possible to see if there were a few users having particularly high response
3 Master Data times or if there was a general performance problem.

4 Business Process If you have system monitoring active with transactions /SDF/MON or /SDF/
Description – SMON, you can jump right into the statistical data record on the recorded time
Inbound Process
stamp.
5 Business Process
Description Procedure:
for Outbound • Go to transaction ST03N and search for the hour with the worst performance
or the highest workload using the time profile.
6 Generic Part
• Call transaction STAD with the following selection criteria:
7 Appendix – Show all statistical records, sorted by start time: Checked
– Start date: Today’s date
8 Legal Require- – Read time: 1 hour
ments – Start time: Start time of high workload (from ST03N)
– User: *
– Response time: >= 5000 minutes
– Task type: D (dialog) or B (batch) or R (RFC) or * (all)

Please be aware that this query may take several minutes.

134 / 143
1 Getting Started The following screenshots show the initial screen of STAD with the options:
Show all statistical records, sorted by start time, reading of the records for
2 Introduction
10 minutes starting from 16:50 hours, for all users (*) that executed dialog
3 Master Data transactions lasting longer than 1,000 minutes.

4 Business Process
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

135 / 143
1 Getting Started The following two screenshots show the result of this query. For each time
stamp, it displays what program was executed within which transaction on
2 Introduction
which server. For each one, the user, response time, time in work process, CPU
3 Master Data time, DB time, GUI time, CUA reference program. and CUA internal command
are displayed. These columns are not all part of the first standard output. They
4 Business Process were adjusted using the “Select output fields” button (F9).
Description –
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

136 / 143
1 Getting Started To simplify the following steps, you can download a list in spreadsheet format.
Make sure that all columns are displayed before downloading. Please be aware
2 Introduction
that the STAD records are only kept in the system for a limited period (normally
3 Master Data 24 or 48 hours).

4 Business Process For further details, add CUA reference program and CUA internal command
Description – to your selection in STAD:
Inbound Process

5 Business Process
Description
for Outbound

6 Generic Part

7 Appendix

8 Legal Require-
ments

Go through the list of high-duration dialog steps and search for those appearing
several times. You may identify which steps belong together by comparing the
transaction, the program, CUA reference program, and CUA internal command.
Use the table below to identify which transaction the dialog steps belong to.

If a CUA ref program or a CUA internal command cannot be found in this list
or if there are doubts on the assignment, please proceed as described below.
Please beware that the table beneath only shows typical CUA internal com-
mands for a few common steps. However, these commands can be different
in the system depending on customized settings, user exits, particular system
usage, and so on.
• Execute the typical steps of the core business processes once. Execute the
steps slowly in sequence and record the exact time they are executed. The
steps should be performed by a key user.
• Go to STAD and display the statistical records related to this single execution
(use the user name and the appropriate time frame to display the correct
records).

137 / 143
1 Getting Started • Format the output list (button “Sel. fields”), including the fields “GUI time,”
“CUA reference program,” and “CUA internal command.”
2 Introduction
• Use the time stamps of the statistical records and the execution times
3 Master Data recorded to assign the “CUA internal commands” or the “CUA reference
program” to the dialog steps that were performed.
4 Business Process • Use this information to identify which dialog steps have extremely high
Description – response times during peak load time.
Inbound Process

5 Business Process Use this information to analyze in detail what is harming the performance of
Description the corresponding transaction or dialog step. Also use the information on the
for Outbound distribution of the response time (DB time, CPU time, GUI time) provided in
the list to identify the cause of the problem. Depending on the result. proceed
6 Generic Part
with a deeper analysis of the worst steps using, for example, transaction ST05
7 Appendix (for long DB times), transaction SE30 (for long CPU times), or a network
analysis (not described in this document) for high GUI times.
8 Legal Require-
ments Additionally search for those taking particularly long (more than 10 seconds,
for example). Contact the responsible user to find out what they were doing
at that time, if they took some unusual steps or noticed a bad response time.
If you cannot identify the cause, use the procedure described for transaction
ST05 for a deeper analysis.

6.4.5 Transaction ST05

The performance trace tool contains a range of trace functions that can be
used to monitor and analyze the performance of the system in database
accesses, locking, and remote calls of reports and transactions. It allows
recording of database access, locking activities, and remote calls of reports
and transactions in a trace file and to display the performance log as a list.
It also provides extensive support for analyzing individual trace records.

To use the performance trace, an authorization to start transaction ST05 is

needed, as well as the following system authorizations “Change trace switches”
(authorization STOM for authorization object S_ADMI_FCD) and “Analyze
traces” (authorization STOR, also for authorization object S_ADMI_FCD).

The performance trace contains the following options:

• SQL trace: This allows monitoring the database access of reports and
transactions.
• In-queue trace: This allows monitoring the locking system.
• RFC trace: This provides information about remote function calls (RFCs)
between instances.

138 / 143
1 Getting Started The aim of the procedure described below is to find the SQL statements that
are causing high response times in SAP S/4HANA. If a transaction or a process
2 Introduction
step that is taking too long is identified, you can use transaction ST05 to find
3 Master Data out if one or more SQL statements are causing the performance problem.

4 Business Process Procedure:

Description – • Call transaction ST05 and make sure the trace executer is on the same
Inbound Process
instance as the user to be traced:
5 Business Process – Check the option SQL trace (also in queue and RFC trace if needed).
Description – Activate the trace with filter.
for Outbound – Enter the user name of the user that will perform the steps.
– Confirm.
6 Generic Part
– Ask the user to perform the relevant steps (and nothing else).
7 Appendix – Deactivate the trace.
– Display the trace. Make sure the user name is correct. Write down the
8 Legal Require- displayed time stamps (trace period) to be able to find the same trace in
ments the system later on. Use the extended trace list to display the time stamps
for each SQL statement.
– Depending on what is being analyzed, it might be wise to let the user
execute all steps twice and use the second execution for the analysis.
This will ensure that all buffers (e.g., program buffers) are filled.
• Go through the trace and search for the statements with a high duration
(marked red). Use the “Explain” functionality to see if the correct index
is being used for that statement.

If it is not possible to find the cause of the performance problem or you need
further assistance for the analysis, contact the next support level or open
an OSS message on component XX-SER-TCC. Attach the trace, a detailed
description of the performed steps, and the related STAD records to the
message.

139 / 143
1 Getting Started 6.4.6 Transaction ST12
The single transaction analysis tool allows you to examine the performance
2 Introduction
of transaction or ABAP programs, such as reports, subroutines, function mod-
3 Master Data ules, or classes – on the coding side tracing the ABAP code as well as on the
database side (SQL trace/performance trace). It saves its results in performance
4 Business Process data files, which can be displayed as lists. These results can be used to identify
Description – runtime-intensive statements, to combine table accesses, and show the hier-
Inbound Process
archy of program calls. From the results of the runtime analysis, the following
5 Business Process can be identified:
Description • Excessive or unnecessary use of modularization units
for Outbound • CPU-intensive program functions
• User-specific functions that could be replaced with ABAP statements
6 Generic Part
• Inefficient or redundant database access.
7 Appendix
ST12 allows you to aggregate the ABAP trace data per modularization unit
8 Legal Require- (subroutine, loop, function call, and so on) and enables you to analyze the
ments ABAP trace in different ways with a graphical help for easily identifying the
call tree structure from different perspectives. The performance trace and
the ABAP trace, if done from within one ST12 trace execution, are kept in
one named version and can be analyzed together.

Note that the ST12 ABAP trace transaction is not officially documented
and is only released for use by SAP or certified service consultants during
SAP service sessions (for example, SAP GoingLive Check or the SAP Solution
Management Assessment service). ST12 is only available in English and
German.

For details about the use of transaction ST12, see SAP Note 755977.

Depending on the size of the program, considerable volumes of data can be

generated during the runtime analysis. For this reason, this tool is defaulted
to aggregation per calling position. This reduces the volume of records for a
loop to the number of occurrences in the coding of a loop – instead of separate
records for each loop cycle. SAP Note 755977 provides more details.

The runtime analysis consists of two parts:

• Recording performance data
• Analyzing the performance data

140 / 143
1 Getting Started In the first part, the system measures the transaction, program, or procedure,
and writes the result to a performance data file. The measurement of certain
2 Introduction
objects can be restricted. It is also possible to measure up to 10 external pro-
3 Master Data cesses. In the second part, the performance data is analyzed, and the system
displays the results in list form. For more information on this transaction and
4 Business Process its usage, please see the application help.
Description –
Inbound Process
The runtime analysis tool measures the CPU time required by the measurable
5 Business Process components of a transaction, a program, or a procedure. The information is
Description stored in a performance data file, which can be analyzed either immediately
for Outbound or later. The CPU time required to measure the runtime is subtracted from
the total CPU usage. If the runtime of a program is measured more than once,
6 Generic Part
you are unlikely to obtain the same result on each occasion. There are various
7 Appendix reasons why it is difficult to obtain identical runtimes. For example, in the first
measurement, the system might read data records from the table buffer on
8 Legal Require- the application server, but in a second run, it may have to read them directly
ments from the database. Runtimes also depend on the overall system or network
load (for example, the number of jobs or systems currently active in the
SAP system).

If you cannot determine the cause of the performance problem or need

further assistance for the analysis, contact the next support level or open
an OSS message on component SV-PERF. Attach the runtime analyses,
a detailed description of the performed steps, and the related STAD records
to the message.

141 / 143
 7 Appendix
1 Getting Started If you are interested in either customizing your warehouse management
monitor and adopting the default subnodes or alternatively creating sub-
2 Introduction
nodes for your own needs, we highly recommend the following blog posts:
3 Master Data • EWM Warehouse Monitor Node
• Advanced Features in SAP EWM Warehouse Monitor
4 Business Process
Description – In general, functionality in SAP EWM and SAP supply chain management
Inbound Process
solutions is shifting from one paradigm to another. As there’s new function-
5 Business Process ality with every release, we also recommend that you to stay up-to-date
Description by following SAP blogs tagged with “extended warehouse management,”
for Outbound using the product help on help.sap.com and the latest versions of the
SAP S/4HANA Operations guide.
6 Generic Part

7 Appendix Stay up-to-date with the SAP Extended Warehouse Management

Community.
8 Legal Require-
ments

142 / 143
 8 Legal Requirements
1 Getting Started Beta and other experimental features
Experimental features are not part of the officially delivered scope that SAP
2 Introduction
guarantees for future releases. This means that experimental features may
3 Master Data be changed by SAP at any time for any reason without notice. Experimental
features are not for productive use. You may not demonstrate, test, examine,
4 Business Process evaluate, or otherwise use the experimental features in a live operating envi-
Description – ronment or with data that has not been sufficiently backed up. The purpose
Inbound Process
of experimental features is to get feedback early on, allowing customers and
5 Business Process partners to influence the future product accordingly. By providing your feed-
Description back (e.g., in the SAP Community), you accept that intellectual property rights
for Outbound of the contributions or derivative works shall remain the exclusive property
of SAP.
6 Generic Part

7 Appendix Example code

Any software coding and/or code snippets are examples. They are not for pro-
8 Legal Require- ductive use. The example code is only intended to explain better and visualize
ments the syntax and phrasing rules. SAP does not warrant the correctness and com-
pleteness of the example code. SAP shall not be liable for errors or damages
caused using example code unless damages have been caused by SAP's gross
negligence or wilful misconduct.

143 / 143
Studio SAP | 88873enUS (23/09)

© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice
for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.