Configuring RF Menus, Transaction Sequences and Screen Layouts
Learn how RF menu trees, transaction codes, and screen sequences are configured and customized in classic WM and EWM so operators see only the functions relevant to their role and warehouse process.
Explanation
RF menus are not just a list of transactions; they are the operational contract between the warehouse process design and what an operator physically sees on a handheld device. In classic ECC/decentralized WM, the RF menu is built as a tree structure accessed through the RF main menu (commonly entered via transaction LM00), where each node points to an RF transaction such as putaway, picking, or physical inventory counting. Menu structures are assigned per warehouse number and can be restricted by user, user group, or presentation device profile, so a receiving clerk sees a different tree than a picker. Screen sequences within each RF transaction are controlled by configuration that determines which fields appear, in what order, and whether values are defaulted, hidden, or mandatory - for example, whether a putaway confirmation screen requires manual entry of the destination bin or accepts a system-proposed bin with a scan-to-confirm step. In EWM (embedded or decentralized), RF processing uses a different framework: RF transactions are built from process-oriented logical transactions tied to warehouse process types and are rendered through the EWM RF framework, typically accessed through an ITSmobile or SAP GUI-based front end. Screen flow customizing in EWM is done through the presentation profile and logical transaction configuration, allowing you to control hotkeys, function key assignments, and step sequences per process. Both worlds share common configuration themes: defining presentation device types (character-based RF guns versus ITSmobile browser-based devices), controlling exception code behavior when an operator cannot complete a step normally, and configuring confirmation logic per movement type (immediate confirmation versus two-step open/confirm). A frequent design decision is how much scanning to enforce - full source and destination bin and HU scans provide the highest data integrity but slow throughput, while partial scanning increases speed but raises the risk of misplacement. Screen layout decisions also affect training time: overly dense screens with many optional fields increase operator errors, especially for seasonal or temporary staff. Because RF screens are used continuously during a shift, even small changes such as reordering fields or changing a default quantity behavior must be tested with actual operators on the real device form factor, since a change that looks fine on a desktop simulator may be awkward on a small handheld screen with limited buttons. Version control of these configurations matters because RF logic changes deployed without adequate testing can halt an entire shift if a screen sequence loop is broken or a scan step becomes unreachable.
Real project scenario
A distribution center introduced a new hazardous-materials putaway process and needed operators to scan a compliance label in addition to the destination bin. The RF team added a mandatory scan step in the screen sequence for that specific storage type, tested it in a sandbox device pool, then rolled it out only to putaway menu nodes reachable by hazmat-trained users, avoiding disruption to unrelated putaway flows.
Common mistakes
• Changing global screen sequences instead of process- or storage-type-specific variants, unintentionally affecting unrelated workflows • Assuming a screen change validated on a GUI simulator will behave identically on the physical RF device • Overloading RF screens with optional fields that slow down high-volume pickers • Failing to restrict menu nodes by user group, exposing functions like stock adjustment to unauthorized operators • Not retesting exception code paths after a screen sequence change, leaving orphaned or unreachable steps
Best practices
• Design menu trees and screen sequences around operator roles and process types, not a single generic flow • Enforce scanning at points where data integrity risk is highest, and relax it only where throughput clearly outweighs risk • Pilot screen changes on actual RF hardware with real operators before full rollout • Keep exception code paths tested whenever screen sequences change • Document menu-to-transaction mapping so support teams can trace an operator issue back to configuration quickly
Interview angle
Interviewers assess whether you understand that RF menu and screen design is a business process control point, not just a UI task, and whether you can explain how menu restriction, screen sequence logic, and exception handling map to real operational risk such as unauthorized stock moves or mis-scans.