JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

June 27, 2026 · 13 min read

SAP EWM RF Logical Transaction

The RF Logical Transaction (RFLT) is the executable unit within the SAP EWM RF Framework — it defines precisely which warehouse function a handheld RF terminal can perform and how the operator interacts with it step by step. Each RFLT encapsulates one complete screen flow for one warehouse task type, such as picking, putaway, packing, or goods receipt. This article maps its definition structure, processing steps, verification controls, and exception-handling behavior, giving EWM consultants and administrators the detail needed to configure, extend, or troubleshoot RF terminal operations.

Part 1: RF Logical Transaction — Core Concepts (All Modules)#

1.1 What Is the RF Logical Transaction?#

An RF Logical Transaction defines one complete, end-to-end interaction sequence between a warehouse worker using an RF handheld terminal and the EWM system for a single warehouse task type. It is the atomic executable unit of the RF Framework: just as a transaction code in SAP GUI opens one functional screen, an RFLT opens one guided RF screen flow on the scanner.

1.2 Standard vs. Custom RFLTs#

SAP delivers a comprehensive set of standard RF Logical Transactions covering the most common warehouse operations. Projects must decide early which standard RFLTs to use as-is, which to enhance, and which scenarios require custom-built RFLTs — a decision that directly affects upgrade effort and support complexity.

Design principle: Use standard RFLTs wherever possible. Copy to customer namespace for enhancements rather than modifying SAP objects. Custom-built RFLTs are justified only for warehouse operations with no standard equivalent (e.g., proprietary label scanning workflows or dual-confirm quality gate steps).

1.3 Organizational Levels and Data Hierarchy#

The RF Framework is organized in a strict four-level hierarchy anchored to the Warehouse Number. The RF Logical Transaction sits at the second level, below RF Environment and above the menu and profile layer. Understanding where each configuration object lives in this hierarchy is essential for correct scope planning in multi-warehouse projects.

Warehouse Number (e.g., WH01)
   │
   └── RF Environment (e.g., ENV01 — screen size, display settings)
          │
          ├── RF Logical Transaction (e.g., PICK, PUT, PACKS)
          │      └── Processing Steps (Step 1: scan HU, Step 2: confirm qty, ...)
          │
          ├── RF Menu (menu tree visible to the operator)
          │      └── RF Profile (user/resource-specific settings)
          │             └── RF Queue (task assignment queue)
          │
          └── RF Presentation Device (registered handheld terminal)

Key design decision: Define one RF Environment per distinct screen size (e.g., 20-row vs. 16-row terminals). Do not mix screen sizes within one RF Environment — field positions will misalign on smaller screens.

1.4 Integration with Other Master Data Objects#

The RF Logical Transaction does not operate in isolation. It is embedded in a web of configuration objects that together determine which operators see which tasks, how tasks are routed to terminals, and how warehouse orders and process types interact with the RF execution layer.

Part 2: EWM-Specific Field Details#

2.0 Scope of EWM Ownership#

Legend: ◎ = Owner / Critical

2.1 Transaction Definition#

The Transaction Definition is the header record of the RF Logical Transaction. It establishes the identity of the RFLT, binds it to the ABAP function module that controls screen processing, and determines which warehouse process type it serves.

2.2 Processing Steps#

Processing Steps define the ordered sequence of screens and scan actions the operator must complete within the RF Logical Transaction. Each step maps to one user interaction — a barcode scan, a quantity entry, or a system-triggered validation. The step sequence is the core of the RFLT’s operational behavior.

2.3 Verification Control#

Verification Control governs how strictly the system validates operator input during the RF session. These settings balance throughput speed against scan accuracy and are among the most operationally sensitive configuration choices in the RF Framework.

2.4 Exception Handling#

Exception Handling defines what happens when an operator cannot complete a step as designed — for example, a bin is physically inaccessible, a product barcode is damaged, or a quantity discrepancy is found. Proper exception configuration ensures that unexpected situations are captured in the system rather than silently bypassed.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction