ALMACÉN Y
ENVÍOS

Cubra todas sus necesidades de gestión de ALMACÉN y ENVÍOS en BUSINESS CENTRAL.
En este artículo explicamos qué debería exigir, cómo evitar las personalizaciones y qué APPS utilizar.

La gestión de almacén trata, básicamente, de gestionar los procesos del almacén. En general, la gestión de inventario en un ERP consiste en gestionar artículos, variantes, cantidades y ubicaciones, y cuando incorporamos la gestión de almacén, también se trata de documentos de envío y recepción y de ubicaciones de almacén (bins).

Normalmente solo sabemos que tenemos 10 artículos en stock, pero con la gestión de almacén sabemos que hay 4 artículos en la estantería A y 6 en la estantería B.

Es importante conocer la diferencia entre un almacén (location) y una ubicación (bin) en Business Central. Un almacén es un lugar geográfico, como una fábrica o una planta. Cada almacén se divide en muchas ubicaciones.

Lo impresionante de adoptar una solución de gestión de almacén es la rapidez con la que todo encaja. Con frecuencia nos encontramos con empresas que quieren implantar una solución de almacén partiendo de una situación sin ubicaciones. Una vez que se ponen en marcha, el sistema lo controla todo.

Solo tenemos que aclarar la terminología, porque la gestión de inventario significa varias cosas en el mundo ERP.

NIVEL 1: GESTIÓN FINANCIERA DEL INVENTARIO
Llevar el control de la cantidad y el valor de cada artículo es la forma financiera y cuantitativa tradicional de entender la gestión de inventario. Es la base para poder controlar los artículos en nuestro sistema ERP. Nos permite comprar un artículo y almacenarlo, y también venderlo y retirarlo del stock.

NIVEL 2: GESTIÓN DE INVENTARIO CON UBICACIONES
Con un sistema de gestión de almacén entran en escena los artículos por ubicación. Además de conocer la cantidad, el sistema también registra en qué ubicaciones está colocado cada artículo. Puede haber doce unidades en una estantería y tres en otra; cada vez que movemos el artículo físicamente, debemos comunicárselo de inmediato al sistema ERP para que todo siga bajo control. Se requiere un nivel de registro completamente nuevo, que exige una solución de escáner.

Procesos internos del almacén

Tenemos una zona de recepción, una zona de picking, una zona de expedición y una zona de reserva. Cuando llega un camión, llevamos rápidamente la mercancía a la zona de recepción y la registramos, pero en ese momento no tenemos tiempo de ubicarla todavía. Entonces necesitamos una lógica inteligente que nos ayude a decidir dónde debe colocarse la mercancía.

Colocamos palés completos en la zona de reserva y después reponemos la zona de picking: tomamos de la reserva y lo llevamos a la zona de picking. También puede ocurrir que movamos mercancía desde el almacenamiento en altura a la zona de picking.

Debemos poder realizar recuentos de inventario y regularizar el stock. Si falta mercancía o está dañada, debemos reducir el stock. La gestión de almacén exige contar por ubicación, y es una tarea que debemos poder hacer con un escáner.

Cuando hay que enviar la mercancía, preparamos un envío de almacén y hacemos el picking de la mercancía para el envío.

Envíos: procesos externos

Los envíos se ocupan de gestionar la parte del envío que tiene lugar fuera del almacén. Tenemos recepciones que llegan al almacén y envíos que salen de él.

Debemos gestionar qué artículos esperamos recibir y planificar cómo enviaremos los artículos a los clientes. Debemos gestionar los albaranes y a los transportistas.

Si recibimos en el almacén un contenedor completo de mercancía, nos gustaría disponer de herramientas para recibirla de forma sencilla. Necesitamos saber qué artículos deberían estar en el contenedor y poder verificar que hemos recibido lo esperado.

Picking y envío

Los artículos pueden prepararse para pedidos de venta o para órdenes de producción. Creamos un picking para que los empleados recojan la mercancía en el almacén y, en la zona de embalaje, empaquetaremos la mercancía en las cajas óptimas y la enviaremos con el transportista.

Tenemos que controlar el número, el volumen y el peso, y tenemos que imprimir etiquetas para las cajas. Es en este proceso donde pasamos de centrarnos en la mercancía y la cantidad a centrarnos en las cajas que hay que enviar, y debemos saber qué contienen todas las cajas.

Necesitamos poder programar los envíos para que los transportistas vengan a distintas horas a recoger los envíos, y necesitamos poder programar el picking y el embalaje para que coincidan con los envíos. Una vez recogida y embalada la mercancía, debe colocarse en la zona de expedición en el orden en que el transportista la va a recoger.

El picking es probablemente el mayor reto matemático. Debemos preparar los pedidos de los que tenemos todos los artículos en stock. Los pedidos de venta deben priorizarse, tanto en relación con los clientes como en relación con el envío, y al mismo tiempo debemos planificar una ruta eficiente en el almacén para el picking y calcular en qué cajas debe embalarse la mercancía.

A menudo los artículos se recogen en un carro, pero lo más inteligente es hacer el picking directamente en la caja. Esto presupone que Business Central puede indicar qué tamaño de caja debe elegir el operario.

3PL y almacén en consigna

También podemos tener stock almacenado en otros lugares, por ejemplo en distribuidores que tienen mercancía en consigna, de modo que cuando queremos reponer su stock, debemos poder hacerlo con órdenes de transferencia.

También puede estar en un almacén de terceros, que se encarga de nuestra gestión de almacén y del envío de nuestra mercancía a los clientes. Esto requiere mucha integración.

Con la gestión de almacén queremos lograr cuatro beneficios, que son:

• Previsibilidad financiera
• Mayor nivel de servicio
• Mínima inmovilización de inventario
• Picking optimizado

Si todavía no dispone de una solución de almacén, debería prepararse a fondo. Por ejemplo, debería analizar lo siguiente:

• qué tamaño tiene su almacén
• cuántos pickings realiza
• el tipo de pickings que necesita
• si quiere hacer el picking para varios clientes a la vez
• si quiere o no hacer el picking para un cliente a través de varios pedidos de venta
• si quiere gestionar el volumen y las dimensiones de los artículos
• si quiere poder hacer el picking de artículos en diferentes unidades de medida
• si los artículos vienen en packs con cantidades distintas y si tienen marcados e identificadores diferentes
• si tiene pickings de tamaño atípico, como una escoba de 2 metros que no cabe en una caja de cartón
• si tiene códigos de barras en todos los lugares donde se necesitan

Pasar del papel a una solución informática de gestión de almacén conlleva mucho trabajo. Repasemos las cuatro ventajas que debemos asegurarnos de obtener al implantar una solución de almacén.

Ventaja 1: Previsibilidad financiera

La primera ventaja es que nuestro inventario es siempre correcto, en contraste con el modelo tradicional, en el que tenemos que hacer un recuento de inventario varias veces al año, lo que nos obliga a reservar varios días en el calendario para contar toda la mercancía… solo para descubrir una discrepancia muy elevada.

Con una solución de almacén es más fácil mantener el stock constantemente actualizado, de modo que nunca se acumula una gran discrepancia.

Lo bueno es que esta ventaja aparece por sí sola. Cuando vamos a recoger un artículo y no está, simplemente registramos una regularización. De este modo, el recuento se realiza de forma continua por ubicación, en lugar de periódicamente por artículo.

La primera ventaja, pues, es la previsibilidad financiera.

En la situación tradicional, en la que contamos el stock varias veces al año, todo el mundo contiene la respiración durante varios días mientras hacemos el recuento, porque nadie sabe si la discrepancia resultará positiva o negativa.

¿Qué tamaño tienen actualmente las discrepancias de inventario? ¿Y cuál es el objetivo con la implantación de una solución de almacén?

Si de repente nos encontramos con una diferencia de millones, repercutirá directamente en el resultado de explotación y provocará caras de preocupación en el departamento financiero.

Ventaja 2: Mayor nivel de servicio

Cuando el inventario es más exacto, también resulta más fácil elevar el nivel de servicio y la tasa de cumplimiento perfecto de pedidos (Perfect Order Fulfilment) que ofrecemos a los clientes.

Si un artículo está dañado, podemos darlo de baja de inmediato. Cuando algo no cuadra, podemos regularizarlo al instante en lugar de esperar a un recuento.

El cumplimiento perfecto de pedidos se refiere a cuántos pedidos de venta entregamos a los clientes de forma perfecta, en el plazo acordado, al precio acordado y sin reclamaciones. Por supuesto, queremos que nuestros clientes estén satisfechos, y lo estarán si reciben lo que quieren, cuando lo quieren. Esa es la esencia de un nivel de servicio alto.

En realidad, no basta con entregar en el plazo confirmado. Según el modelo SCOR (Supply Chain Operations Reference), el nivel de servicio «verdadero» debe medirse en función de lo que los clientes quieren recibir. Si podemos ofrecerlo, hacemos bien nuestro trabajo.

Si nuestro nivel de servicio es demasiado bajo, probablemente se trate de mercancía que tenemos dificultades para conseguir a tiempo, porque la planificación no es lo bastante rigurosa o porque tenemos un plazo de entrega de salida corto y un plazo de suministro de entrada largo; por ejemplo, si compramos mercancía en China y la entrega tarda 6 meses, pero el cliente espera poder comprar el artículo con un día de antelación.

Así que tenemos un reto. En esta situación, necesitamos tener la planificación firmemente bajo control.

Sin embargo… además de este reto tradicional, también debemos pensar en la gestión de inventario.

Si creemos que el artículo está en stock y lo vendemos, pero resulta que el stock está vacío, tenemos un problema importante entre manos.

Para alcanzar un buen nivel de servicio es esencial que el inventario cuadre. Por eso necesitamos una gestión de inventario con actualización en tiempo real.

Ventaja 3: Mínima inmovilización de inventario

Al mismo tiempo, una solución de almacén nos permite reducir el capital inmovilizado en inventario.

Es una eterna cuestión de prioridades: elevar el nivel de servicio aumentando los niveles de stock, o minimizar el capital inmovilizado y convivir con un nivel de servicio más bajo o con mayores costes de reaprovisionamiento.

Una gestión de inventario detallada nos da más posibilidades de salirnos con la nuestra en ambos frentes.

Si nuestra gestión de inventario es un caos y no podemos estar seguros de si hay discrepancias en el stock, necesitamos comprar cantidades mayores para asegurarnos de tener suficiente en stock, con lo que aumenta la inmovilización de liquidez.

Cuando podemos gestionar el inventario con más precisión, podemos comprar con más acierto y así reducir el valor del inventario sin que afecte al nivel de servicio.

Ventaja 4: Picking optimizado

Una de las cosas a las que más atención prestan las empresas al implantar una solución de almacén es el picking de pedidos de venta: la capacidad de hacer el picking en el almacén y de ser guiado por el almacén siguiendo una ruta de picking óptima. Un picking óptimo consiste en la ruta más corta e inteligente posible.

Existen muchos modelos distintos de estructuración de pickings. Por eso debemos tener claro qué requisitos tendrá en cuenta la solución ERP al organizar los pickings. Normalmente hay que considerar muchos escenarios distintos.

Si tenemos muchísimos pedidos de venta, muchos de ellos para el mismo cliente (por ejemplo, si suministramos a una gran cadena minorista y tenemos diez pedidos de venta abiertos para ella, de los cuales algunos son pedidos pendientes, otros son para mañana y otros eran para ayer), la solución de inventario debería combinar de forma inteligente un picking que abarque varios pedidos de venta.

Quizá queramos hacer un «picking masivo» (bulk pick), recogiendo de una vez para 20 pedidos de venta distintos de diferentes clientes, porque son pedidos relativamente pequeños; cuando llegamos a la zona de expedición, separamos los artículos y los colocamos en cajas. Esto se denomina «picking masivo».

También puede ser que queramos trabajar con «picking por caja» (box picks), en el que recogemos directamente en el embalaje de envío. Si tenemos que hacer el picking para cuatro pedidos de venta, la solución de inventario nos pedirá que recojamos en cuatro cajas distintas.

El sistema debe controlar el volumen y haber calculado de antemano qué tamaño deben tener esas cajas. Esto nos evita tener que reembalar los artículos en la zona de expedición, porque hemos recogido directamente de la estantería al embalaje de envío. Esto se denomina «picking por caja» o «picking por palé» según el tipo de embalaje.

Además, puede que queramos recoger antes de las 9 de la mañana todo lo destinado al extranjero, porque es la hora a la que el transportista viene a recoger los envíos al extranjero. Por tanto, la solución de inventario debe asegurarse de organizar los pickings de modo que no estemos recogiendo todos los pedidos con destino local, que luego ocupan espacio en el muelle de carga cuando llega el camión con destino al extranjero.

En cuanto al picking, existen muchos requisitos distintos que son decisivos para nuestra capacidad de optimizar el almacén. Por supuesto, el operario no tiene por qué preocuparse de todo esto. El terminal de mano simplemente debe guiarlo por la mejor ruta.

«Coja un carro con dos cajas, de tamaños 3 y 5. Recoja los artículos siguiendo esta ruta.» El sistema debe organizar todo esto para el operario.

Cuando se ha completado un pedido, la solución de almacén debe crear los documentos de envío e integrarse con los transportistas.

Lo importante es que la solución se encargue de reservar al transportista para que venga a recoger y de transmitir todos los datos necesarios, de modo que no se requiera ningún procesamiento manual.

Algunas empresas pueden prescindir de terminales con escáner, pero solo porque tienen un almacén pequeño y trabajan con ubicaciones fijas.

El primer paradigma de una solución de almacén, por tanto, es que debemos registrar todo lo que ocurre en el almacén; en la práctica, esto a menudo solo es viable con una solución de registro mediante escáner.

La mayoría de las empresas necesitan dispositivos para realizar los registros en el almacén. Pueden ser costosos terminales de mano, escáneres para carretillas o simplemente smartphones que ejecutan una versión móvil del sistema ERP Business Central.

Si tenemos un almacén pequeño, esto puede hacerse de forma muy sencilla, directamente desde un cliente móvil hacia Business Central. Pero es imprescindible alguna forma de solución de registro.

En línea o sin conexión

Y la primera decisión que hay que tomar al respecto es si trabajaremos en línea con el sistema ERP o sin conexión. Es decir, si queremos que nuestros registros se actualicen en el sistema ERP sin demora (en línea) o por lotes (sin conexión).

Si todo se actualiza en línea en el sistema ERP, un vendedor puede crear un pedido de venta que se enviará de inmediato al almacén, donde el pedido puede prepararse al instante.

En muchas soluciones de almacén, los pickings se generan por la mañana, cuando un proceso por lotes del sistema calcula cuánto debemos preparar a lo largo del día; después crea todos los pickings y recibimos una hoja de trabajo con lo que tenemos que hacer hoy.

Los sistemas más recientes crean un picking cada vez. Cuando el operario está libre o ha terminado un picking, pulsa un botón en su terminal para obtener los detalles del siguiente, y entonces el sistema le crea el siguiente picking. Esto significa que, si acaba de entrar un nuevo pedido de venta de máxima prioridad, será el siguiente en prepararse.

También puede ocurrir que hayan entrado artículos en recepción hace un momento, y el sistema ya ve que ese artículo está disponible y empieza a permitir que se incluya en los pickings. El debate sobre si el registro debe realizarse en línea o sin conexión es muy importante. La planificación de pickings en tiempo real tiene sus ventajas, por supuesto, pero eso no significa que sea siempre la mejor solución.

Por ejemplo, debemos tener en cuenta la calidad de nuestra cobertura de red. Trabajar en línea requiere, naturalmente, acceso ininterrumpido a internet. Normalmente se instalan puntos de acceso por todo el almacén, y esto es fácil mientras se trate de un almacén interior corriente.

Normalmente recomendamos trabajar en línea siempre que sea posible, pero si no tenemos cobertura de internet ininterrumpida, tendremos que trabajar sin conexión.

Equipamiento

Las decisiones comentadas arriba pueden determinar el tipo de terminales de mano que necesitamos, pero por lo demás:

Si tenemos muchos pickings y muchos operarios en un almacén grande, normalmente hay un buen argumento de negocio para elegir terminales con escáner propiamente dichos y con muchas funciones, capaces de soportar un uso ininterrumpido y de resistir que los atropelle una carretilla elevadora.

Si tenemos un almacén relativamente pequeño y solo queremos realizar registros ocasionales, quizá nos baste con una tableta o un teléfono móvil conectado directamente al sistema ERP. Son mucho más baratos, pero también bastante más frágiles.

El volumen es lo que determina principalmente la elección del equipamiento.

Profundicemos en algunos de los requisitos funcionales que a menudo plantean dificultades en una nueva solución de almacén.

Packs

Vendemos un artículo, por ejemplo una cola, por unidad, y cada lata de cola lleva un código de barras, pero se empaquetan en packs de 6.

¿Debemos, por tanto, tener un código de barras distinto en el exterior del pack, o debe ser el mismo código de barras? En ese caso, ¿tendremos que acordarnos de registrar 6 unidades al escanear un pack?

Si los packs de 6 se empaquetan en una caja con 24 en total, ¿esa caja también tiene un nuevo código de barras?

Ahora bien, si hay códigos de barras distintos en la cola y el sistema puede reconocer la cantidad, el mismo principio se aplica a todos los demás artículos. De lo contrario, los errores de picking son inevitables. Para gestionar bien este reto en el sistema ERP, el sistema debe admitir una estructura de artículos con packs de cantidades variadas.

De lo contrario, resultará engorroso de gestionar, ya sea en la estructura de artículos del sistema ERP o en la situación de escaneo en el almacén. Debemos controlar bien los packs y las cantidades con las que hacemos el picking.

Códigos de barras

Cuando implantamos una nueva solución de almacén, las tareas que más tiempo consumen incluyen introducir los códigos de barras en nuestro sistema ERP, configurar las ubicaciones y colocar etiquetas en todas las estanterías del almacén donde queremos utilizar terminales de mano para escanear.

Tiene poco que ver con la solución ERP en sí; es un trabajo de baja tecnología que hay que hacer. Por desgracia, hay muchas empresas que no tienen códigos de barras en todos sus artículos ni en todas sus piezas.

Por ejemplo, si somos una empresa de alimentación y compramos un lote de coliflores, no se entregará con un código de barras en cada coliflor. Entonces, ¿cómo las registramos? ¿Debemos tener el código de una coliflor en la cabeza, o tenemos que acercarnos a un tablón y hojear hasta la imagen de una coliflor para poder escanear un código de barras?

Este problema no se limita a la industria alimentaria. El escaneo de códigos de barras es un reto en muchos sectores.

Unidades de medida alternativas no lineales

Hay otro gran reto para los sistemas ERP en el almacén: las diferentes unidades de medida. La mayoría de los sistemas ERP gestionan perfectamente los códigos de unidad. Almacenamos la cola enlatada por unidad, pero también la tenemos en un pack de 6 y en un pack de 24.

Lo resolvemos creando relaciones entre códigos de unidad en el sistema ERP. Así, tenemos unidades, packs, bandejas, cajas, bultos, etc. La mayoría de los sistemas ERP lo gestionan sin problemas.

Lo difícil son las unidades de medida no lineales.

Un ejemplo clásico podrían ser los pollos congelados. Vendemos pollos congelados en cajas de 20. También vienen 20 por caja cuando los compramos, pero la liquidación, tanto en ventas como en compras, se hace por el peso real.

Pedimos un palé, que son 40 cajas, a nuestro proveedor. Cuando llegan, registramos la recepción de 40 cajas en la línea de compra del sistema ERP, y este calcula por sí mismo que son 800 unidades.

En la práctica, sin embargo, cuando las escaneamos en el almacén, puede que escaneemos cada caja por separado y registremos el peso, que puede resultar ser de menos kilos de lo que pensaba el comprador. Los pollos pueden variar mucho de peso, y queremos gestionarlo también en el ERP.

En última instancia, todo debe liquidarse según el peso, de modo que el sistema ERP debe controlar varias unidades de medida no lineales para el mismo artículo. Nos referimos a esto como códigos de unidad alternativos o «segunda unidad de medida» en la terminología ERP.

Si importamos jamones de Italia y los compramos en cantidad, puede haber grandes variaciones. Los jamones pesan entre 1,2 y 3,5 kilos cada uno. Nuestro cliente pide 3 jamones y se le entregan 3, pero el pago debe hacerse por peso. En esta situación es crucial que nuestro sistema ERP controle las unidades.

Por regla general, el reto para el sistema ERP no es que las unidades de medida cambien entre la compra y la venta. Eso es bastante fácil de gestionar siempre que las unidades de medida sean lineales, de modo que 1 kg equivalga, por ejemplo, a 8 unidades.

El sistema ERP trabajará con una unidad base, normalmente la que se utiliza para el recuento de inventario y en la que se almacenan los artículos desde el punto de vista financiero. Aunque compremos 100 kg, el sistema lo almacenará en términos de la unidad base, como una cantidad de 800.

Sin embargo, cuando la relación es no lineal, no siempre existe una unidad base natural, y las cosas empiezan a complicarse en el sistema ERP.

No tiene ninguna gracia tener 100 metros de tablones en stock si todos miden solo 20 cm porque son recortes de madera cortada a medida para los clientes. ¿En qué unidad contaremos los tablones si tenemos que hacer un recuento de inventario? «Varios» es probablemente la mejor respuesta.

En el ERP se requiere un sistema aparte de tipos de movimiento para gestionar los distintos códigos de unidad entre bastidores.

No queremos que esto se desarrolle a medida en nuestro sistema ERP, ya que es una tarea de gran envergadura. Queremos que lo gestione la solución de gestión de almacén.

Fraccionamiento

Quizá también necesitemos gestionar el fraccionamiento (breakbulk) en el almacén. Vemos que tenemos 10.000 latas de cola en stock, pero quizá no vemos en qué formato de embalaje están. ¿Cuántas están empaquetadas en packs de 6 o en cajas de 24?

En el ejemplo de los jamones anterior, un cliente podría pedir 3 jamones, cada uno de al menos 2,8 kilos. ¿Debería nuestro sistema poder decirnos si podemos entregar? Puede que podamos entregar 3 unidades, y también 8,4 kilos, pero eso no significa necesariamente que podamos entregar 3 unidades de al menos 2,8 kilos cada una.

Si tenemos un almacén de madera y compramos tablones de longitudes fijas, ¿cuántos detalles debe controlar el sistema ERP? Quizá vemos que tenemos 400 metros en stock, divididos en 200 tablones, pero no qué longitudes tienen.

Si un cliente pide 100 tablones de 3 metros, puede que tengamos suficiente en stock tanto en longitud como en cantidad, pero, si muchos de ellos se han cortado en piezas pequeñas, no tenemos garantizado disponer de 100 tablones de 3 metros.

Si queremos saber qué tablones podemos preparar realmente, el sistema ERP debe tener firmemente bajo control tanto el fraccionamiento como los códigos de unidad.

La trazabilidad de artículos, ya sea la gestión de fechas de caducidad o la gestión ordinaria de números de lote o de serie, es un asunto clásico. Business Central debe admitirla con elegancia (y sí, hay muchas formas poco elegantes de gestionarla).

Hay muchos sectores en los que la trazabilidad de artículos es ya relevante o un requisito indiscutible.

Números de lote y números de serie

Básicamente, existe la trazabilidad por número de lote (también llamado número de partida) y existe la trazabilidad por número de serie.

La diferencia es que el número de serie es único para cada unidad. Siempre es una cantidad de 1 unidad la que tiene un número de serie único. Los números de serie son muy habituales, por ejemplo, en la industria electrónica.

Los números de lote se utilizan cuando un artículo se produce por lotes y todas las unidades de ese lote reciben un número de lote para poder reconocerlas. Esto puede aplicarse a productos líquidos que se pueden trasvasar o a mercancías ordinarias que se pueden recoger. Desde luego, puede aplicarse a artículos que se producen en cantidad pero reciben un número de lote porque se producen por lotes.

Por ejemplo, podría haber 5.000 bandejas de paté producidas de una sola vez y que por tanto reciben el mismo número de lote. O un metro cúbico de pequeñas piezas de plástico, etc.

Uno de los criterios para elegir la gestión por número de serie es que el número de serie debe estar en el artículo individual. De lo contrario, no tiene sentido.

También hay sectores que ponen tanto números de lote como números de serie en el mismo artículo, para indicar que un determinado número de serie se produjo en una determinada producción por lotes.

Business Central sabe gestionar números de lote y de serie. Una vez que un artículo se ha configurado para indicar si tiene número de lote o de serie, Business Central lo gestiona perfectamente a lo largo de toda la jerarquía.

Si vamos a producir esas 5.000 bandejas de paté, por ejemplo, y compramos carne y leche, en las recepciones registramos un número de lote en los artículos comprados.

Y, si no recibimos un número de lote del proveedor, podemos crear el nuestro, formado por una fecha y un número identificador. De este modo sabemos cuándo se recibió cada materia prima y de qué proveedor.

Cada vez que manipulamos las materias primas en el almacén, indicamos el número de lote de los artículos que retiramos. Cuando las materias primas se incorporan a la producción de un producto terminado o quizá de un producto semiacabado, registramos los números de lote incluidos, y el resultado de la orden de producción recibe un nuevo número de lote trazable.

Una bandeja de paté acaba así como una jerarquía de números de lote, lo que nos permite profundizar a través de la jerarquía y rastrear todas las materias primas incluidas en una bandeja de paté concreta.

Si identificamos una materia prima problemática, podemos subir por la jerarquía y localizar todos los productos terminados que incluyen el número de lote de la materia prima problemática.

Esta es la trazabilidad de artículos tradicional, algo que el sistema ERP puede admitir de forma muy sencilla.

Es evidente que la trazabilidad de artículos exige más registros en el almacén y en la producción, pero debemos asegurarnos de que la estructura del sistema ERP no añada dificultad. Siempre deberíamos poder «salir escaneando». Debemos minimizar los registros manuales.

Sin introducción manual

Normalmente, o bien tendremos el número de lote en nuestras materias primas o bien imprimiremos etiquetas con el número de lote cuando produzcamos el artículo.

Así, por ejemplo, si producimos un artículo al que el sistema asigna automáticamente un número de lote, el sistema debe poder imprimirlo de modo que aparezca en una etiqueta con un código de barras y, por tanto, pueda escanearse fácilmente.

No debería ser necesario teclear nada manualmente. Deberíamos poder gestionar el artículo exclusivamente mediante el terminal con escáner. Esto puede configurarse en la mayoría de las soluciones de almacén.

Es posible que tengamos algunos artículos con trazabilidad y otros sin ella. La leche y la carne del paté tienen trazabilidad por número de lote, pero la sal y la pimienta quizá no. La mayoría de los sistemas pueden gestionarlo.

Gestión de fechas de caducidad

Normalmente surgen dificultades en Business Central en lo que respecta a la gestión de fechas de caducidad. Cuando compramos un artículo, en él figura cuándo caduca, y debemos poder registrarlo en el sistema ERP.

Y, cuando producimos un artículo, debemos poder seleccionar una fórmula de fecha de caducidad en la ficha del artículo para que el sistema calcule una fecha, por ejemplo 1 año a partir de la fecha de producción, e imprima esa fecha de caducidad concreta en el sistema.

Esto en sí es razonablemente sencillo para la mayoría de los sistemas ERP

Las cosas se complican un poco cuando consideramos la «vida útil restante» (remaining shelf life, RSL).

Vida útil restante

Cuando nuestro cliente compra el artículo que caduca 1 año después de la fecha de producción, el cliente puede fijar un requisito sobre la cantidad de vida útil restante. Cuando el artículo llega a la estantería del supermercado, este puede exigir que la vida útil restante sea al menos del 75 %.

El requisito de vida útil restante no siempre se expresa en días; puede ser un porcentaje de la vida útil total del artículo.

Nuestros clientes normalmente tendrán requisitos de vida útil restante diferentes, y puede ser muy difícil gestionarlo y lograr que el sistema ERP lo tenga en cuenta al calcular los pickings de inventario.

Para empezar, el algoritmo de picking debería ser lo bastante inteligente como para preparar los artículos de los clientes con los requisitos menos restrictivos, de modo que reciban los artículos más antiguos. De este modo podemos estar seguros de cumplir los requisitos de vida útil restante en el mayor número posible de pedidos.

Nuestros clientes también pueden complicar un poco las cosas estipulando «lote único» (single batch), es decir, que el cliente insiste en que todo el envío tenga el mismo número de lote, o «lote único por capa» (single-layer batch), donde todas las capas de un palé deben tener el mismo número de lote.

Muchos clientes establecen este tipo de requisitos porque no quieren escanear muchos números de lote distintos, con cantidades diferentes, en su zona de recepción.

El «lote único» facilita mucho las cosas al cliente, pero complica más nuestro sistema ERP.

Si tenemos un cliente que hace un pedido grande con el requisito de «lote único», el sistema ERP probablemente tendrá que preparar primero el pedido de ese cliente para estar seguro de poder entregar. Pero esto puede provocar conflictos.

Si otro cliente solo exige un 50 % de vida útil restante, en realidad queremos preparar primero el pedido de este cliente, porque entonces podemos tomar el artículo más antiguo. Sin embargo, si este picking divide un lote, puede que no podamos entregar en absoluto el gran pedido de «lote único».

En realidad, por tanto, a menudo debemos considerar primero a los clientes con los requisitos de «pedido único» más restrictivos y tener en cuenta la vida útil restante después.

Esto se convierte enseguida en un ejercicio matemático en el que el sistema ERP debe hacer malabares con todos los requisitos y combinar artículos para que se prepare el mayor número posible de pedidos.

Como mínimo, esto exige que el inventario sea 100 % correcto.

Y exige una solución de gestión de almacén que planifique bien los pickings según todos los criterios que establecen los clientes.