Ese campo no falta. No está configurado.

Read this post in English →

A dos pantallas RF les falta un campo. La queja que llega del almacén es idéntica, y el pantallazo del ticket también: “no está el campo”.

Una se arregla en diez minutos de parametrización. La otra es un desarrollo ABAP de verdad, con especificación, transporte y tiempo de un programador.

Nada en la pantalla del operario indica cuál es cuál. Saber distinguirlas antes de abrir el ticket es la diferencia entre resolverlo esta tarde y meterlo en el sprint que viene.

En los dos posts anteriores vimos el menú de RF — a qué transacciones puede llegar un trabajador, y cómo el Presentation Profile y el Personalization Profile deciden eso por rol. Este post trata de lo que pasa después de que un trabajador llega a una transacción: la pantalla en sí, sus campos, sus botones, y si todo eso encaja en el dispositivo que tiene en la mano. Es otra capa de Customizing distinta — el Display Profile y el Screen Manager — y buena parte de ella no necesita a un desarrollador en absoluto.

El RF Framework tiene tres capas, y solo una de ellas son “pantallas”

Conviene saber dónde estás antes de cambiar nada. El RF Framework se divide en:

• Capa Dynpro — las pantallas reales. Toda pantalla RF es una template screen (el marco exterior: cabecera, botones de función, línea de error) o una service sub-screen (lo que cambia dentro de ese marco en cada paso — los campos de entrada concretos de ese escaneo).
• Capa de lógica de negocio — la transacción lógica: la secuencia de pasos, qué módulo de función se ejecuta con qué código de función, y en qué orden.
• Content provider — los propios módulos de función (PBO — Process Before Output, PAI — Process After Input) que leen y escriben datos de verdad.

El Display Profile y el Screen Manager viven enteramente en la capa Dynpro. Añadir un campo que no existe en ninguna parte de la estructura subyacente es trabajo de lógica de negocio/content provider — eso sí es el ticket de ABAP. Redimensionar lo que ya está ahí, o activar/desactivar un campo existente, es Customizing de capa Dynpro — la parte que muchas veces puedes hacer tú mismo.

Crear un Display Profile nuevo

Todo almacén tiene un display profile estándar de fábrica (SAP lo entrega como **), dimensionado para un dispositivo de referencia genérico. Las RF guns reales rara vez coinciden con él. Para adaptar las pantallas al hardware real — por ejemplo, un handheld de 12 líneas y 20 columnas — se copia el perfil estándar en vez de editarlo directamente:

1. RF Screen Manager (IMG: SCM Extended Warehouse Management → Extended Warehouse Management → Mobile Data Entry → Radio Frequency (RF) Framework → RF Screen Manager), pestaña Display Profile. Se introduce ** como origen, se usa Copy Profile y se nombra el nuevo perfil (p. ej. H1). Se ajustan Screen Height y Screen Width al dispositivo real, y se acorta Menu Item Length para que quepa.
2. Se introduce un grupo de funciones para las nuevas template screens (p. ej. ZRF_H1_TMPL). El sistema lo genera y copia las dos template screens estándar de RF a ese grupo, ya en el nuevo tamaño.
3. En Sub-Screen Location, se marca el checkbox Create Sub-Screens y se indica un segundo grupo de funciones (p. ej. ZRF_H1_SUBSCREEN). Esto copia todas las subscreens del framework al nuevo tamaño de una sola vez — incluidas las generales (logon, logoff, menú), no solo las de las transacciones de aplicación. Si se deja ese checkbox sin marcar, esas quedan fuera, no solo las específicas de cada transacción.
4. Se revisa la pestaña Screens del nuevo perfil. Cada subscreen tiene un semáforo: verde significa que la conversión encajó sin problemas; cualquier otro color significa que algún campo no cabía en el nuevo tamaño y el sistema lo acortó automáticamente.

Un perfil con más espacio de pantalla que el estándar también necesita ajuste manual — el propio libro muestra el ejemplo de mover botones en el editor de pantallas (transacción SE51 o SE80) para hacer crecer una subscreen de ocho a diez líneas, y luego añadir líneas de menú extra usando los campos de la estructura /SCWM/S_RF_SCRELM, con el grupo de pantalla 003 marcado para que el RF Framework sepa desactivar las líneas que no se usan.

Una vez que las pantallas existen, el perfil todavía tiene que llegar a un dispositivo: Maintain Presentation Devices (/SCWM/PRDVC), donde se crea una entrada (p. ej. HAND) y se le asigna el nuevo display profile. Se marca Default si la pantalla de login de ese dispositivo debe usar este perfil automáticamente.

Activar o desactivar campos y botones — sin ABAP

Buena parte de “la pantalla no encaja con lo que necesitamos” no es un campo ausente en absoluto — es un campo que existe en la pantalla estándar pero está configurado al revés. Todo campo de una pantalla RF puede ser de entrada, obligatorio o visible de forma independiente, y los campos de verificación (los que un operario tiene que volver a escanear para confirmar, como una ubicación o una handling unit) se activan o desactivan de la misma manera. Si una regla de negocio dice “no pidas producto en este escaneo”, eso muy a menudo es un cambio de checkbox en el Customizing del campo — no una petición para un desarrollador.

Los botones funcionan igual. Cada pantalla/paso puede llevar hasta cuatro botones de función estándar (PB1–PB4) definidos en un function code profile, además de la opción de disparar la misma función solo por teclado (FNKEY) sin mostrar ningún botón — o mostrar el botón sin tecla de función. Si se deja PUSHB en blanco, solo funciona la tecla; si se deja FNKEY en blanco, solo aparece el botón. Quitar un botón que no hace falta, o desactivar un botón de Guardar en una pantalla donde no debería aparecer, es el mismo tipo de cambio: localizar el paso y el estado de esa pantalla, y vaciar o reasignar el slot correspondiente.

Encontrar el paso y el estado correctos es lo único que vale la pena memorizar: entrar al entorno RF (/SCWM/RFUI), navegar hasta la pantalla en cuestión, y pulsar Ctrl+Shift+F1. Eso abre una ventana de datos técnicos que muestra la transacción lógica, el paso y el estado exactos detrás de la pantalla que se está viendo — las mismas tres coordenadas que hacen falta en Define Steps in Logical Transactions para que cualquier cambio se aplique de verdad.

Volviendo al pallet con SSCC

Y el campo SSCC ausente. Si ya existe un campo para SSCC en algún punto de la estructura subyacente de esa pantalla y simplemente está oculto o desactivado, es un arreglo de capa Dynpro: localizar el paso/estado con Ctrl+Shift+F1, activar el campo como visible y de entrada en el Customizing, listo. Si no existe ningún campo así en la estructura — nada que activar — entonces sí es trabajo genuino de lógica de negocio/content provider: un desarrollador añade el campo a la pantalla en el Screen Painter y extiende el módulo de función PAI para procesarlo. En un caso real, el arreglo fue exactamente eso: indicarle al desarrollador ABAP la transacción lógica (ULDLSI), el paso (ULCRHU) y el programa de pantalla (/SCWM/SAPLRF_UNLOADING) que necesitaban el nuevo campo SSCC — con la precisión suficiente para que ninguna de las dos partes tuviera que adivinar nada. Saber en cuál de las dos situaciones estás, antes de abrir el ticket, es exactamente el objetivo de entender esta capa.

La frase que vale la pena recordar: el Menu Manager decide a qué puede llegar un trabajador. El Display Profile decide qué le cabe una vez que llega.

Referencia rápida

Dónde	Transacción / IMG	Qué se hace ahí
RF Screen Manager	IMG · Mobile Data Entry	Crear/copiar un display profile dimensionado para el hardware real
SE80 / SE51	Transacción	Ajustar manualmente el layout de template y subscreens tras copiar un perfil
Define Steps in Logical Transactions	IMG · Mobile Data Entry	Activar/desactivar entrada, obligatoriedad, visibilidad de campos; editar el function code profile (PB1–PB4, FNKEY)
/SCWM/PRDVC	Transacción	Asignar un display profile a un dispositivo de presentación
/SCWM/RFUI + Ctrl+Shift+F1	Transacción	Encontrar la transacción lógica, el paso y el estado detrás de cualquier pantalla

Lecturas relacionadas

• ¿Por Qué Cada Trabajador del Almacén Ve un Menú RF Distinto? — el concepto detrás del Presentation Profile y el Personalization Profile
• Cómo Construir un Personalization Profile en RF, Paso a Paso — el Customizing de nivel de menú sobre el que se apoya este post

Parte de la serie RF. ← Cómo Construir un Personalization Profile en RF, Paso a Paso · Siguiente: Tu operario escanea cuatro códigos para mover un palé. Tres sobran. — qué campos tiene que escanear realmente el operario, y cómo pasar de cuatro a dos.