Routing en SAP EWM MFS: ¿cuándo control de almacenamiento y cuándo routing BFT?

1. Introducción

El control de almacenamiento orientado al layout fue el primero. Se utilizó sobre todo para transporte de palés; para instalaciones de contenedores, sencillamente no existía una solución adecuada. El routing para transporte de contenedores llegó más tarde.

De este orden surgieron los nombres y, con ellos, un malentendido persistente. El routing BFT no solo funciona para instalaciones de contenedores, sino que puede utilizarse igualmente en un transporte de palés. Qué lógica se acaba empleando depende de cómo esté diseñada e implementada la instalación, y no de lo que viaje sobre la cinta.

Lo decisivo es el reparto de tareas entre EWM y el control lógico programable. ¿Con qué grado de detalle decide EWM y cuánta búsqueda de rutas se deja a la instalación?

Por ello, la elección de una lógica de routing no debería basarse en la mercancía transportada, sino en la interfaz de telegramas, en la lógica de los puntos de notificación y en la cuestión de dónde debe tener lugar la búsqueda de rutas.

A continuación repasamos ambas lógicas de routing: mecánica básica, customizing y los puntos en los que el estándar deja de ser suficiente.

Encontrará una visión general del control de la tecnología de almacén automatizada directamente desde SAP EWM en nuestra página de servicios SAP EWM Control del flujo de materiales.

2. Fundamentos técnicos

Ambos procedimientos responden a la misma pregunta: ¿adónde debe ir la unidad de manipulación (HU) a continuación? El camino hasta la respuesta, sin embargo, es muy distinto.

2.1 Control de almacenamiento orientado al layout (LOLS)

El control de almacenamiento orientado al layout interviene siempre que un movimiento no puede ir directamente de la ubicación de origen a la ubicación de destino, sino que debe pasar por una ubicación intermedia. Ejemplo clásico: un palé debe entrar en la estantería de gran altura. Antes, sin embargo, se realiza el control de contorno y peso en el punto de identificación; después pasa al punto de transferencia hacia el transelevador, y solo desde allí a la ubicación de almacenamiento definitiva en la estantería.

El mecanismo es una cadena:

• La tarea de almacén hacia el destino real (A → D) se crea como inactiva. El destino, por tanto, se conoce en todo momento.
• En paralelo se crea una tarea de almacén abierta hacia la siguiente ubicación intermedia (A → B).
• Al confirmar en B, la ubicación de origen de la tarea de almacén inactiva cambia de A a B y se vuelve a comprobar: ¿hay desde aquí otra ubicación intermedia? Si es así, se crea la siguiente tarea de almacén abierta (B → C).
• Si es posible un movimiento directo al destino, la tarea de almacén inactiva se activa y se ejecuta como último tramo.

El camino no se genera por adelantado, sino tramo a tramo, cada vez que se confirma el anterior. Y una restricción más: sin unidades de manipulación, LOLS no funciona.

Detrás de una ubicación intermedia hay prácticamente siempre un punto de notificación al que se ha asignado una ubicación. Con ello aún no se dice hasta dónde llega un tramo: el siguiente destino intermedio no tiene por qué ser el siguiente cruce ni el punto de notificación posterior. El tamaño de los saltos depende de cuánta búsqueda de rutas esté implementada en el control.

Existen opciones alternativas, pero solo de forma limitada. Mediante el número de secuencia pueden mantenerse varias ubicaciones intermedias. Si B está ocupada, puede encontrarse B1. Esto, no obstante, solo vale para el siguiente paso. C solo se comprueba cuando C pasa a ser la siguiente ubicación intermedia actual. En el estándar no se evalúan rutas completas con antelación.

Esto se mantiene en dos lugares del customizing que conducen a la misma definición: en Sistema de flujo de materiales (MFS) → Control de almacenamiento o en Ajustes interprocesos → Tarea de almacén.

Relevante para los equipos de proyecto y de customizing:

La estructura de /SCWM/TROUTL explica por sí misma el mecanismo: como selección sirven el tipo de almacén de origen y la sección de almacenamiento de origen (VLTYP/VLBER), así como el tipo de almacén de destino y la sección de almacenamiento de destino (NLTYP/NLBER), es decir, desde dónde y hacia dónde. El resultado es la siguiente ubicación intermedia (ILTYP/ILBER/ILPLA). Mediante el número de secuencia (SEQNR) pueden almacenarse alternativas. La tabla no puede representar una ruta completa; un registro describe siempre un solo paso.

2.2 Routing para transporte de contenedores

De la HU, una instalación de transporte de contenedores suele conocer solo el código de barras, y hay que decidir de inmediato, porque el contenedor no espera. Por eso, en cada punto de notificación se determina, a partir de los atributos de la HU, hacia dónde continúa. Izquierda, derecha, recto.

Tres cosas son decisivas:

• Solo se lee. La propia decisión de routing no crea ninguna tarea de almacén ni cambia ningún estado.
• Se avanza de cruce en cruce. Al PLC, por regla general, solo se le envía una dirección.
• Siempre hay respuesta. A través del registro por defecto, el PLC recibe en cualquier caso una dirección, si es necesario hacia el punto de aclaración.

Como criterio sirve el área de actividad, es decir, el destino funcional de la HU, o su estado en EWM: defectuosa, vacía, sin orden. Si ninguno de los registros mantenidos coincide, se aplica el valor propuesto.

Técnicamente, el routing consta de tres componentes que trabajan juntos como capa de traducción. EWM piensa en estados; el PLC solo conoce salidas.

Relevante para los equipos de proyecto y de customizing:

La definición de routing propiamente dicha en /SCWM/TMFSROUTE combina PLC y punto de notificación (PLC/CP) con el criterio de selección (LD_EWM o AAREA) y devuelve la dirección (LD_PLC). Opcionalmente puede mantenerse un punto de notificación de destino en el que se contabiliza la HU. El registro del movimiento se realiza entonces de forma asíncrona o sobre la base del routing real que el PLC comunica de vuelta a EWM.

De dónde procede el área de actividad queda abierto: puede provenir de la determinación aproximada de ubicación, pero igualmente de una tarea de almacén de producto o de HU ya existente. Para la decisión de routing esto no importa; solo se lee el resultado.

A diferencia de LOLS, a la tabla le falta un campo de número de secuencia. Por tanto, en el estándar no pueden almacenarse rutas alternativas para puntos de notificación bloqueados.

2.3 El verdadero criterio de distinción

En lugar de «palés aquí, contenedores allá», describe mucho mejor la situación el reparto de tareas:

2.4 El customizing de un vistazo

En el árbol SPRO, ambas lógicas se encuentran bajo el mismo nodo, pero en ramas separadas.

3. Entrada en el almacén automático: por qué funciona decidir tarde

Un caso especial merece un capítulo propio, porque va más allá de los fundamentos: cómo trabaja el transporte de contenedores en la entrada al almacén automático de piezas pequeñas.

Si la entrada en un almacén automático se realiza a través del transporte de contenedores, la lógica puede llevar a cabo ya en el estándar una determinación aproximada de ubicación, y esta puede ejecutarse de forma asíncrona. El proceso desacopla movimiento y decisión:

• Escaneo en el punto I: la HU se identifica y continúa de inmediato.
• La determinación aproximada de ubicación se ejecuta en segundo plano. La instalación no espera.
• En el siguiente escáner, la HU se dirige hasta el pasillo a partir del resultado aproximado.
• Solo inmediatamente antes del transelevador se determina el destino concreto y se crea una tarea de almacén para el recurso.

Se decide, por tanto, lo más tarde posible y, al principio, solo con la precisión necesaria. En LOLS es al revés: allí el destino figura desde el principio en la tarea de almacén inactiva. Una instalación que en cada entrada espera a la determinación completa de la ubicación no puede seguir el ritmo de la velocidad de los contenedores.

4. Decisiones de arquitectura: qué hay que aclarar en el blueprint

La decisión más importante se toma en el Business Blueprint, al coordinar la interfaz de telegramas con el fabricante de la instalación. Allí se ve qué espera el control como destino y cuánta búsqueda de rutas asume por sí mismo. De ello resulta la lógica de routing adecuada.

La trampa está en el propio término. El hecho de hablar de una instalación de palés no implica que tenga que ser control de almacenamiento. Quien basa la decisión en la expresión «transporte de contenedores» en lugar de en la interfaz acaba rápidamente en la variante equivocada y lo advierte solo cuando el customizing ya está hecho.

4.1 En BFT, el rendimiento es un tema de arquitectura

En el transporte de contenedores, el tiempo de respuesta a una consulta de routing es la condición de contorno central. El contenedor está en el cruce esperando una dirección; cualquier retraso repercute de inmediato en el rendimiento.

De ello se derivan algunas reglas estrictas para las ampliaciones:

• En la ruta de routing debe haber código eficiente. Sin algoritmos muy complejos, sin determinaciones desmesuradas.
• Ninguna contabilización en el propio routing. Todo lo que escribe alarga el tiempo de respuesta.
• Ejecutar de forma asíncrona, si es posible, las determinaciones y contabilizaciones costosas, tal como muestra la determinación aproximada de ubicación del capítulo 3.

Como regla práctica para ampliaciones propias: lo que en el BAdI de routing no se procesa en pocos milisegundos no debe estar ahí.

4.2 Cola o envío directo: una diferencia fundamental

Una diferencia de arquitectura que apenas se aprecia en el customizing afecta al camino del telegrama hacia el PLC. En el control de almacenamiento, cada tarea de almacén que debe ir al control acaba primero en una cola relevante para el PLC. Esta cola se lee y solo entonces sale la tarea de almacén.

Este paso intermedio tiene una utilidad práctica. Antes de enviar puede comprobarse si el siguiente punto de notificación o el siguiente segmento transportador tiene todavía capacidad para recibir la HU. Si no es así, la tarea de almacén simplemente permanece en la cola. El palé ni siquiera se envía. Lo mismo ocurre cuando el PLC notifica una avería en un medio de transporte.

Los límites de capacidad pueden aplicarse a puntos de notificación, segmentos transportadores o recursos. Por cierto, los segmentos transportadores solo hay que definirlos si se quiere gestionar su estado y su capacidad en EWM. A menudo basta con mantener ambos en los puntos de notificación.

El transporte de contenedores no tiene esta etapa intermedia. En el estándar solo se determina la dirección, el telegrama de respuesta se genera directamente en el código y se envía de inmediato. Sin búfer, sin comprobación previa de capacidad, sin posibilidad de retener una consulta.

4.3 Dimensionar correctamente el procesamiento de telegramas

Volvamos al rendimiento, esta vez desde el punto de vista de la infraestructura. En una instalación en funcionamiento, varios puntos de notificación consultan a la vez, y lo hacen de forma permanente, no solo en los picos.

• Permitir varios procesos paralelos para el procesamiento de telegramas. Un único proceso se convierte en cuello de botella en cuanto varios puntos de notificación consultan al mismo tiempo.
• Diseñar el procesamiento de telegramas en un servidor de aplicaciones independiente, de modo que siempre haya suficientes procesos disponibles y la operación en diálogo no interfiera.
• Desacoplar los telegramas de estado del routing: varios canales por PLC, por ejemplo uno para consultas de routing y otro para mensajes de estado.

La separación de canales se pasa por alto con frecuencia. Según el tamaño de la instalación, se acumulan muchísimas consultas de routing, y cada una bloquea un contenedor. Los mensajes de estado, en cambio, son mucho menos frecuentes y no son críticos en el tiempo; ni siquiera tienen que procesarse dentro de la secuencia de telegramas. Si, aun así, todo pasa por el mismo canal, un solo mensaje de estado puede frenar las consultas de routing que esperan detrás.

Cómo supervisar la comunicación de telegramas en operación y acotar las averías lo describe nuestro artículo «Monitorización de telegramas en SAP EWM MFS: reintentos, canales CP, colas bloqueadas y depuración en la práctica».

4.4 Otros escollos

Otro punto es la colocación de los puntos de notificación. Por un lado, en el customizing: las acciones que crean, modifican o confirman tareas de almacén no deberían dispararse en puntos de notificación muy próximos entre sí; de lo contrario, existe el riesgo de conflictos de bloqueo en el procesamiento de TA.

Por otro lado, de forma muy física en la instalación: si dos puntos de notificación están demasiado juntos, queda muy poco tiempo entre las dos consultas. En el customizing todo parece correcto; el problema aparece solo en tiempo de ejecución.

5. Comparación práctica: el mismo proceso con dos lógicas de routing

5.1 Reubicación con LOLS

Tomemos el layout de palés del capítulo 2. En el puesto de picking 1 ha terminado la extracción y el palé empezado debe volver a la estantería, en concreto al pasillo 3, a la ubicación 0083-05-04-03. Directamente no es posible: entre KP1-OUT y el pasillo hay dos puntos de notificación y el punto de entrada al almacén.

Así se abre camino el control de almacenamiento orientado al layout:

En ningún momento existe una descripción continua de la ruta. El destino figura desde el principio en la tarea de almacén inactiva, pero el camino hacia él se va generando poco a poco, cada vez que se confirma el tramo anterior. Si la comprobación ya no devuelve ninguna ubicación intermedia, se activa la tarea de almacén inactiva, que asume el resto.

El último tramo, de EP3 a la ubicación de almacenamiento, lo recorre el transelevador. Con ello se aplica la regla del capítulo 3: los recursos siempre necesitan una tarea de almacén, independientemente de la lógica de routing en el recorrido.

Si falta uno de los cuatro registros en el customizing, por ejemplo el de CP2 en dirección al pasillo 3, la comprobación no encuentra nada. No existe un valor propuesto que entre en juego. En su lugar se activa la tarea de almacén inactiva y el PLC recibe un telegrama con un destino al que no puede acceder desde esa posición.

5.2 Cuando el punto de entrada al almacén está ocupado

La cosa se pone más interesante cuando surge un imprevisto. La HU va de camino en la tarea de almacén abierta CP2 → EP3, pero EP3 está ocupado. No se puede depositar allí, así que pasa de largo y sigue su vuelta por el bucle.

Qué ocurre entretanto en EWM:

• La HU se notifica de nuevo en el siguiente punto de notificación conocido, aquí CP1.
• La tarea de almacén abierta CP2 → EP3 se confirma con el código de excepción CHBD. CHBD significa Change Destination Bin y permite modificar la ubicación de destino al confirmar; es decir, se contabiliza en CP1 en lugar de en EP3.
• El destino 0083-05-04-03 de la tarea de almacén inactiva se mantiene y su ubicación de origen se desplaza a CP1.
• Con la confirmación se vuelve a evaluar el control de almacenamiento orientado al layout, esta vez a partir de CP1. Y allí existe una entrada en dirección al pasillo 3 vía CP2.
• Se crea una nueva tarea de almacén abierta CP1 → CP2 y la cadena de tramos se ejecuta por segunda vez.

La HU da, por tanto, una vuelta y vuelve a intentarlo mientras EP3 siga ocupado. No es elegante, pero funciona, porque el bucle conduce inevitablemente a la HU de nuevo por una posición que está mantenida como posición de origen en el control de almacenamiento orientado al layout.

En el transporte de contenedores este caso no se daría así, porque allí se vuelve a decidir en cada punto de notificación, sin confirmación previa. Un punto de entrada ocupado sería solo una decisión de dirección que esta vez resulta distinta.

5.3 El mismo camino con routing BFT

La misma tarea en el layout del AKL: una HU llega y debe ir al pasillo 3. Aquí no hay cadena de tramos ni una sola tarea de almacén por el camino.

En el punto de entrada BFT1-IN se escanea la HU y se controla el contorno; al mismo tiempo se inicia la determinación aproximada de ubicación. La HU, sin embargo, no espera al resultado: sale ya, en dirección 1.

Hasta EP3 solo se ha leído: sin confirmar, sin código de excepción, sin tarea de almacén inactiva en segundo plano. La tarea de almacén se crea solo donde es estrictamente necesaria, a saber, para el transelevador.

También se aprecia bien el papel del valor por defecto. En SC6 recoge el caso de que la determinación aproximada de ubicación aún no haya terminado o no haya sido posible; entonces la HU se vuelve a expulsar. En SC1 y SC2, default significa poco más que «no es mi pasillo, sigue adelante».

5.4 Vía de entrada llena en BFT

Si la vía hacia EP3 está ocupada, el PLC, según su programación, sigue recto de todos modos. La HU da entonces su vuelta por el bucle mediante el routing por defecto y vuelve a intentarlo en la siguiente pasada por SC3, hasta que la vía de entrada queda libre.

Sin error, sin intervención, sin tarea de almacén bloqueada. La HU sigue en movimiento y, en algún momento, funciona.

En comparación con el capítulo 5.2: en LOLS había que contabilizar la posición divergente y volver a montar la cadena. En BFT, en cambio, en EWM no ocurre nada especial. La HU vuelve a pasar, se lee y la decisión se toma de nuevo.

6. Límites: lo que ninguno de los dos enfoques ofrece

Ambos procedimientos chocan con el mismo límite, aunque por motivos distintos: son mecanismos de decisión y no búsqueda de rutas. Quien necesite una optimización de rutas real o una lógica de desvío ante averías tiene que desarrollarla por su cuenta en ambos casos, solo que en lugares distintos.

6.1 Lo que LOLS no puede hacer

• Ninguna evaluación de rutas completas. Siempre se considera únicamente el siguiente paso.
• Las alternativas mediante el número de secuencia actúan exclusivamente a nivel local, nunca a lo largo de varios tramos.
• Ningún valor por defecto. Lo que no está mantenido, no existe.

Sobre todo el último punto tiene consecuencias. Si falta un camino en el customizing, por lo general se activa la tarea de almacén inactiva y se envía al PLC un telegrama con un destino inalcanzable. Operativamente es más desagradable que una cancelación limpia, porque el error solo se hace visible en la instalación y no en EWM.

Las contabilizaciones divergentes son posibles mediante el código de excepción CHBD; entonces, sin embargo, también debe estar registrado en el control de almacenamiento orientado al layout cada camino que pudiera salir mal. Esto escala mal y rara vez se detecta en la fase de pruebas.

6.2 Lo que BFT no puede hacer

• En el estándar no están previstas rutas alternativas para puntos de notificación bloqueados.
• El customizing es relativamente rígido; una búsqueda de rutas compleja tendría que desarrollarse.
• EWM no conoce la topología que hay detrás de una dirección y, por eso, no puede desviarse en absoluto.

6.3 Una debilidad que se convierte en fortaleza

Lo que a BFT le niega la ruta alternativa la hace robusta en operación. Como en cada punto de notificación existe un registro por defecto, el PLC siempre recibe una respuesta. Un contenedor nunca se detiene: en caso de duda, se dirige al punto de aclaración y se retira así del sistema por sí mismo. Si en LOLS falta el registro adecuado, en cambio, el palé se queda parado.