Poka-yoke en almacén: confirmar la ubicación del picking

Una confirmación comprueba un dato concreto

En picking, una etiqueta parecida puede dirigir al operario a otra ubicación. La confirmación de ubicación compara el lugar leído con el asociado al trabajo. Para interpretarla, identifica qué dato pide cada pantalla y bajo qué condición aparece.

En Microsoft Dynamics 365 Supply Chain Management, la función de location confirmation pide verificar que la ubicación coincide con la asociada al trabajo. Microsoft indica que, cuando existe un dígito de control para esa ubicación, el trabajador debe introducirlo; si no hay uno asociado, ese paso se omite. La página también limita la función a situaciones en que la ubicación se rellena automáticamente por el sistema. Microsoft Learn, “Batch, serial, license plate, and location confirmation”, líneas 31–47

Oracle Retail WMS RF Release 14.1 describe otra pantalla específica. En Unit Picking, el sistema presenta una ubicación pendiente, el usuario escanea su ID y los campos Loc y Conf Loc deben coincidir antes de continuar al siguiente paso. Es el flujo documentado en ese manual de versión, no una descripción de todo producto Oracle ni de todos los almacenes. Oracle Retail WMS RF User Guide 14.1, cap. 5, “Unit Picking”, pasos 1–6

Ambos manuales comparan una ubicación con la que tiene asignada la tarea, pero sus pantallas no son iguales. Y esa coincidencia responde solo a una pregunta: ¿se leyó el lugar esperado? No confirma por sí misma el artículo, la cantidad, el lote ni el destino de salida.

Microsoft Dynamics 365: la confirmación depende de cómo se carga la ubicación

La documentación de Microsoft explica que la función se aplica cuando el sistema completa automáticamente el campo de ubicación. Si el operario introduce la ubicación manualmente en el dispositivo móvil, la confirmación se omite, incluso si la función está habilitada en el elemento de menú. Ese límite cambia la interpretación de una captura: ver que una opción está activada no demuestra que cada operación haya pasado por la comprobación.

El ejemplo de Microsoft se puede resumir así:

El menú y la ejecución de una tarea son pruebas distintas. Microsoft vincula la confirmación al origen del campo: si el sistema rellena la ubicación, puede pedir la lectura; si la persona la introduce manualmente, el paso se omite.

Por eso, una captura de configuración no basta para explicar qué ocurrió en una tarea concreta. Para reconstruirla, conviene conservar la versión, el tipo de trabajo, el menú activo, el origen de la ubicación y el registro de la lectura o del mensaje.

Así se separa una capacidad configurada de un control efectivamente recorrido, sin atribuir al producto resultados que la guía no mide.

Oracle Retail WMS RF 14.1: campos que deben coincidir

En el flujo Unit Picking de la guía Oracle Retail Release 14.1, el usuario inicia el picking de unidades, recibe la ubicación con una tarea abierta y escanea el ID del lugar donde está el artículo. El manual explica que los campos Loc (Location) y Conf Loc (Confirm Location) deben coincidir. Después, el usuario reconoce el mensaje y el proceso abre la pantalla de cantidad. La guía es explícita sobre la igualdad de esos campos en ese flujo.

El pasaje Group Unit Pick sigue otra secuencia: la aplicación dirige a la primera ubicación de la lista y pide confirmarla; después solicita confirmar el artículo mediante ID o UPC. La documentación indica el paso, pero el extracto no especifica qué ocurre ante cada tipo de discrepancia. No conviene rellenar ese silencio atribuyendo una respuesta que la fuente no muestra.

La secuencia importa al leer una captura o un log. En Unit Picking, la guía sitúa la confirmación de ubicación antes de volver a la pantalla de picking; en Group Unit Pick, la guía describe luego una identificación de artículo por ID o UPC. Son pasos documentados por separado. Un registro que solo muestra la pantalla de ubicación no prueba que el paso de artículo ocurriera después.

Este recorrido pertenece al manual Oracle Retail WMS RF 14.1. Úsalo para nombrar los campos y el orden que describe esa versión; para explicar una instalación concreta hay que identificar su producto, versión y pantalla. El manual no mide cuántos errores evita la confirmación, así que no permite atribuirle por sí solo un resultado operativo.

Oracle WMS Cloud: una opción configurable en Pick Cart

Una nota de novedades de Oracle WMS Cloud 26D, etiquetada “Idea Lab”, describe el parámetro confirm-active-location para el módulo Pick Cart. Según la página, la selección vacía o Location Scan Required requiere escanear la ubicación activa; Location Scan Not Required omite ese escaneo y solicita SKU o cantidad. La nota explica que la opción responde a situaciones de operaciones de alto volumen donde las ubicaciones activas ya se controlan mediante escaneo de artículo y visualización de ubicación.

Es una función y racionalización de producto publicadas por Oracle, no una prueba independiente del resultado en campo. Oracle WMS Cloud 26D, “Control active location scan in pick cart”, líneas 1–16

La posibilidad de elegir si se solicita el escaneo hace que el parámetro sea parte central de la interpretación. Un registro de picking sin lectura de ubicación no permite concluir, por sí solo, que el sistema falló: la configuración podría permitir omitir ese paso en ese flujo. Pero tampoco permite asegurar que el control se produjo. Para entender el dato, se debe revisar el parámetro vigente, el módulo y la configuración real.

La guía Pick Cart 26C contiene dos pasajes que conviene leer juntos. La nota inicial dice que, ante un conflicto de lote, caducidad o atributos al recoger una SKU desde una LPN o ubicación activa, el flujo no solicita confirmación. Más adelante, la sección “Support Batch, Expiry, and Inventory Attributes During Pick Cart” describe el parámetro prompt-batch-expiry-attr y tres ajustes: en blanco, Always Prompt y Prompt for Conflicting Values.

Por eso, la nota inicial no debe resumirse como una regla para todas las configuraciones. Para describir un caso, hace falta leerla junto con el valor del parámetro y los requisitos de seguimiento del artículo. Oracle WMS Cloud 26C, “Pick Cart”, nota inicial, líneas 8–11; sección “Support Batch, Expiry, and Inventory Attributes During Pick Cart”, líneas 173–197

La sección de configuración condiciona esos prompts a que item-barcode-scan esté en Scan each SKU o Prompt SKU y a que el artículo tenga activado el seguimiento de los datos correspondientes. Los atributos A–G solo se solicitan cuando el artículo los marca como requeridos. En blanco, el parámetro no solicita lote, caducidad ni atributos; Always Prompt pide los valores que el artículo siga; Prompt for Conflicting Values solo pide los necesarios cuando hay más de una línea de inventario coincidente.

La guía también indica que, si se siguen lote y caducidad, solicita lote porque identifica la caducidad. Oracle WMS Cloud 26C, “Pick Cart”, líneas 182–197 y 208–214

La página no aclara de forma expresa cómo se relaciona la nota inicial con el apartado de prompts configurables. Una descripción prudente nombra el módulo, el parámetro, su valor y el seguimiento configurado para el artículo; no afirma que Pick Cart siempre omita o siempre solicite esos datos. Tampoco se puede deducir qué ajustes están activos en un almacén concreto a partir de la guía.

Una situación hipotética en un almacén

Supongamos un pedido ficticio para el artículo A-17, asignado a la ubicación R-04-02. El operario llega a R-04-03, cuya etiqueta es visualmente similar, y escanea el ID. La diferencia entre la ubicación escaneada y la asignada sería el dato relevante para un control que compare ambas referencias. El supuesto no describe un incidente real ni un comportamiento garantizado por todas las plataformas.

Una nota de análisis podría separar estos campos:

El supuesto solo muestra que las ubicaciones difieren. Para analizar una incidencia real, registra el ID de la tarea, el valor asociado a ese trabajo, el dato leído, el origen del campo y el mensaje o la pantalla siguiente con su hora. Esa secuencia permite separar el valor esperado, la entrada y la respuesta observada.

Si el mensaje no aparece en el registro, queda pendiente; no puede completarse a partir de la configuración. La tabla sirve como plantilla editorial, no acredita una operación ni simula una plataforma.

Al redactar el hallazgo, cita el dato asignado y el leído, la fuente del valor y la respuesta registrada. «Leí R-04-03» describe una entrada; afirmar que la tarea permitió continuar exige el mensaje o log correspondiente.

Ubicación, artículo, cantidad y unidad logística

Las fuentes sitúan cada dato en un paso distinto. Microsoft documenta controles separados para ubicación, lote, número de serie y matrícula logística. Oracle Retail muestra la secuencia de ubicación y, en Group Unit Pick, la identificación del artículo. Pick Cart de Oracle Cloud condiciona los prompts de lote, caducidad y atributos a los parámetros y al seguimiento del artículo. Nombrar el paso concreto evita resumir toda la tarea como un solo “picking validado”.

GS1 define el SSCC como identidad de cada unidad logística creada durante el picking en su modelo de procesos para atención sanitaria. Ese identificador puede aportar trazabilidad de la unidad que se mueve, pero el pasaje no describe una comprobación de ubicación. SSCC y confirmación de ubicación son funciones conceptualmente distintas: una identifica una unidad logística; la otra compara un lugar con una referencia de trabajo.

GS1, Model for Supply Chain Processes in Healthcare, Part I, §4.1, p. 13, extracto web

En un registro, “escaneo correcto” es demasiado impreciso. Indica qué se leyó —por ejemplo, el SSCC o el ID de ubicación— y con qué valor se comparó. El lector podrá entonces distinguir identidad de la unidad y confirmación del lugar, en vez de tener que inferirlo del término genérico.

Qué evidencia permitiría describir el control

Para reconstruir un evento concreto, registra en una misma ficha la tarea, producto y versión, módulo, parámetro vigente, ubicación asociada, valor leído y mensaje o respuesta posterior. Esos campos relacionan la configuración con los datos de esa operación. La tabla distingue qué evidencia puede responder cada pregunta y qué punto sigue sin probar.

Cada artefacto responde a una escala distinta: una captura refleja la configuración en el instante en que se tomó; el log, los pasos que el sistema registró para una tarea; el manual, el flujo documentado para una versión. Relaciónalos por tarea, fecha y producto para no presentar una configuración observada después como la del evento ni una guía como registro de ejecución.

Una revisión puede ordenar esas piezas por pregunta:

Al completar la tabla, separa la regla del producto del relato de la tarea: el manual sostiene la primera y un log o captura del momento sostiene la segunda. Un documento de producto no acredita que se ejecutara el paso; el log de ubicación no demuestra por sí solo artículo, cantidad o lote. Si falta el mensaje o la pantalla siguiente, no atribuyas una respuesta al sistema.

Para interpretar el evento, distingue tres etapas: si la configuración solicita la lectura, qué valores compara la pantalla y qué respuesta quedó registrada. En Dynamics, el origen automático o manual de la ubicación condiciona la solicitud; en Retail RF, Loc y Conf Loc deben coincidir; en Pick Cart, el parámetro puede requerir u omitir el escaneo activo. Así se comparan controles por su función, no solo por la etiqueta “confirmación”.

Diferencias de versión y límites del ejemplo

Los ejemplos ocupan puntos distintos del flujo: Dynamics 365 condiciona la confirmación a cómo se rellena la ubicación; Retail RF contrasta Loc y Conf Loc antes de la cantidad; Pick Cart 26D permite configurar el escaneo de la ubicación activa. Para comparar dos operaciones, alinea módulo, pantalla y paso, y después observa la regla y la respuesta. La etiqueta “confirmación de ubicación” por sí sola no demuestra que los controles sean equivalentes.

Ninguna de estas fuentes mide la tasa de error antes y después de activar una confirmación. Para estimar ese efecto habría que definir qué cuenta como error y comparar registros de la misma instalación en periodos y condiciones comparables. Este artículo describe campos y pasos de producto; no asigna una mejora cuantitativa a ninguna opción.

Preguntas frecuentes

¿Qué compara Dynamics 365 en la confirmación de ubicación?

La ubicación escaneada debe coincidir con la asociada al trabajo. Microsoft especifica que la función se aplica cuando el sistema rellena la ubicación.

¿Cuándo puede omitirse la confirmación en Dynamics 365?

La documentación indica que el paso se omite cuando la ubicación se introduce manualmente en el dispositivo móvil.

¿Qué son Loc y Conf Loc en Oracle Retail WMS RF 14.1?

En Unit Picking, la guía indica escanear el ID de ubicación y que los campos Loc y Conf Loc deben coincidir.

¿El SSCC confirma que el operario está en la ubicación correcta?

No. GS1 describe el SSCC como identidad de una unidad logística creada durante el picking; por sí solo no confirma una lectura de ubicación.

¿Cuándo solicita Oracle WMS Cloud 26C lote, caducidad o atributos en Pick Cart?

Depende de prompt-batch-expiry-attr, de item-barcode-scan y de los datos que el artículo tenga configurados para seguimiento. En blanco no solicita esos valores; las otras opciones se aplican según la configuración y los conflictos descritos en la guía.