Un operario mueve un palé de una ubicación a otra. Diez metros, puede que quince segundos de recorrido real. Antes de dejarle confirmarlo, el sistema le pide escanear cuatro códigos: HU origen, ubicación origen, HU destino y ubicación destino.
Multiplícalo por cada movimiento interno, en cada turno. Escanear cuesta más que mover.
Nadie decidió que fuera así. Es lo que el sistema hace por defecto, y así se queda hasta que alguien le dice otra cosa. Este post trata del ajuste que decide qué campos tiene que escanear el operario — y cómo pasar de cuatro a dos sin perder la comprobación que de verdad importa.
Lo que escanea el operario es una decisión de parametrización, no una fatalidad
En los tres posts anteriores fuimos hacia dentro: a qué transacciones llega un trabajador (el menú RF), cómo construir ese menú por rol (Personalization Profiles) y qué cabe en la pantalla una vez que llega (el Display Profile). Este post es la capa siguiente: de los campos que hay en esa pantalla, ¿cuáles exige el sistema que se escaneen antes de aceptar la confirmación?
SAP los llama verification fields. Son los campos que el RF framework pide confirmar al operario — normalmente escaneando un código de barras — al confirmar una warehouse task. Un detalle útil antes de buscarlos en una pantalla: en las pantallas RF estándar, el campo de verificación está a la derecha del campo que verifica. El de la izquierda muestra lo que el sistema espera; el de la derecha es donde el operario lo demuestra.
Campos de verificación típicos en una pantalla de confirmación:
SrceHU— handling unit de origenSBin— ubicación de origenDestHU— handling unit de destinoDstBin— ubicación de destinoProd— productoBatch— loteA Qty— cantidad real
Cuáles de ellos están activos no lo fija la transacción. Lo gobierna un verification profile, y ese perfil puede ser distinto para procesos distintos que pasan por la misma transacción RF.
Por qué cuatro escaneos en un movimiento interno es el valor por defecto equivocado
Escanear sirve para detectar errores. La pregunta es qué error estás intentando detectar exactamente.
En un movimiento interno de una handling unit completa, la HU es la que lleva la identidad. Si el operario escanea la HU de origen correcta y la de destino correcta, el movimiento queda verificado: palé correcto, sitio correcto. Los dos escaneos de ubicación confirman algo que el escaneo de la HU ya ha establecido, porque el sistema sabe dónde está esa HU y a dónde dice la tarea que debe ir.
Compáralo con el picking, donde el cálculo es completamente distinto: ahí sacas parte de una cantidad de una ubicación, así que ubicación, producto, lote y cantidad aportan información que nada más confirma. Mismo framework, mismo almacén, respuesta opuesta.
De eso va el verification profile: permite que dos procesos usen reglas distintas en vez de imponer la más estricta a todo el mundo.
La parametrización, en dos pasos
Montar esto son siempre dos movimientos, y saltarse el segundo es la razón habitual de que alguien diga «creé el perfil y no cambió nada».
Paso 1 — Definir el verification profile
Crea un perfil y enumera los campos que debe verificar. Para el caso del movimiento interno, eso significa HU de origen y HU de destino, y nada más. Los sistemas suelen venir con un par de perfiles ya creados, así que mira qué existe antes de añadir una entrada nueva — puede que ya haya uno que encaje.
Paso 2 — Definir la determinación
Un perfil por sí solo no hace nada. La determinación es lo que le dice al sistema cuándo aplicarlo: en qué proceso, en qué operación de almacén. Es el paso que hace que la misma transacción RF se comporte de una manera en un movimiento interno y de otra en un picking.
Aquí conviene saber dos cosas. Primera: los campos con los que se determina el perfil son a su vez configurables, igual que la secuencia en la que el sistema los evalúa — así que lo que veas en tu sistema depende de cómo se montó esa determinación, y merece la pena mirarlo antes de dar nada por supuesto. Segunda: una vez determinado, el verification profile sobrescribe los campos de verificación definidos en la transacción RF. Manda el perfil. Eso es justo lo que lo hace útil, y también por qué un perfil determinado de forma demasiado amplia puede cambiar sin ruido el comportamiento de procesos en los que no estabas pensando.
Probarlo sin adivinar
Crea una warehouse task ad hoc de handling unit con /SCWM/ADHU, confírmala en el dispositivo RF y mira qué campos pide la pantalla. Si la determinación es correcta, la pantalla de confirmación pide ahora los dos campos de HU y para ahí.
Si sigue pidiendo los cuatro, el perfil casi con seguridad está bien y lo que no encaja es la determinación — ahí es donde hay que mirar primero, no en el perfil que acabas de construir.
Volviendo a los cuatro códigos
Dos escaneos en vez de cuatro, en un movimiento que dura quince segundos, repetido en cada movimiento interno de cada turno. La verificación que importaba — palé correcto, sitio correcto — sigue ahí. Lo que desapareció fue la parte que confirmaba algo que el sistema ya sabía.
Referencia rápida
| Dónde | Transacción / IMG | Qué haces ahí |
|---|---|---|
| Verification Control | IMG · Extended Warehouse Management · Mobile Data Entry | Definir el verification profile y sus campos de verificación |
| Determinación específica por almacén | IMG · Extended Warehouse Management · Mobile Data Entry · Verification Control | Decidir en qué proceso y operación aplica cada perfil |
/SCWM/ADHU | Transacción | Crear una WT ad hoc de HU para probar el resultado |
/SCWM/RFUI | Transacción | Confirmar la tarea por RF y ver qué campos se piden realmente |
Una nota sobre los nombres: la propia documentación de SAP no es del todo consistente aquí — encontrarás el mismo objeto llamado verification profile en la mayoría de sitios y validation profile en otros, y en la comunidad se usan los dos. Se refieren a lo mismo.
Lecturas relacionadas
- ¿Por Qué Cada Trabajador del Almacén Ve un Menú RF Distinto? — Presentation y Personalization Profiles
- Cómo Construir un Personalization Profile en RF, Paso a Paso — la parametrización a nivel de menú
- Ese campo no falta. No está configurado. — Display Profiles y el RF Screen Manager
Parte de la serie RF. ← Ese campo no falta. No está configurado. · Siguiente: cómo llega el trabajo al operario — colas, recursos y grupos de recursos.
Deja un comentario