Integración de WMS para pequeñas operaciones de comercio electrónico
La pregunta de cuándo vale la pena integrar un sistema de gestión de almacenes surge antes de lo que la mayoría de las pequeñas operaciones de comercio electrónico esperan. Las hojas de cálculo funcionan bien hasta que dejan de hacerlo, y el punto de inflexión no suele ser el volumen de pedidos, sino su complejidad: múltiples SKU con seguimiento de variantes, paquetes de productos, pedidos pendientes por falta de existencias repartidos entre varios centros de preparación de pedidos o la necesidad de mostrar cifras precisas de la cantidad disponible para comprometer en pedidos durante el proceso de pago. Este artículo recoge nuestra experiencia al integrar GreaterWMS con una pequeña operación de comercio electrónico: qué funcionó, qué requirió más diseño del previsto y en qué casos las hojas de cálculo siguen siendo la opción adecuada.
Por qué GreaterWMS
GreaterWMS es un sistema de gestión de almacenes de código abierto con una API REST, un backend en Django y un frontend en Vue. Permite gestionar inventario en varios almacenes, realizar seguimiento de lotes, gestionar órdenes de entrada y salida y generar informes básicos. El código se mantiene activamente y la documentación de la API, aunque no es exhaustiva, cubre las operaciones principales.
Lo elegimos frente a las alternativas alojadas por dos razones. Primero, ya operábamos infraestructura autoalojada y no queríamos añadir otra dependencia de SaaS con precios por pedido al aumentar el volumen. Segundo, al ser de código abierto, podíamos ampliar el modelo de datos sin esperar el ciclo de solicitudes de funciones de un proveedor. Para una pequeña operación con necesidades específicas de seguimiento de la caducidad de los lotes, esa flexibilidad era importante.
Nuestro despliegue consiste en un stack de Docker Compose con la aplicación Django, PostgreSQL y Redis; el archivo Compose del proyecto original solo incluye los contenedores de frontend y backend, y la configuración predeterminada utiliza SQLite. Funciona sin problemas junto a otros servicios en un VPS modesto. La configuración inicial lleva unas horas; el trabajo de integración requiere bastante más tiempo.
Patrones de integración de API
GreaterWMS utiliza autenticación basada en tokens. Cada usuario tiene un token (el valor openid), que se envía en un encabezado de solicitud personalizado token, en lugar de como token Bearer en el encabezado Authorization. No incorpora un flujo OAuth ni un mecanismo de rotación de claves de API, por lo que conviene crear un usuario de servicio dedicado con permisos mínimos en lugar de utilizar una cuenta de administrador.
La API sigue en gran medida el estilo REST y utiliza cargas útiles JSON. Los principales recursos de una integración de comercio electrónico son: goods (el catálogo de productos en la terminología del WMS), inventory (los niveles actuales de existencias por almacén y producto), inbound orders (órdenes de compra y devoluciones) y outbound orders (pedidos de clientes para su preparación y envío).
Establecimos pronto una regla: nunca llamar a la API del WMS de forma síncrona desde el proceso de pago. El WMS no forma parte de la ruta crítica de la transacción; si responde con lentitud o no está disponible temporalmente, no debe impedir que el cliente complete la compra. Todas las interacciones con el WMS pasan por una cola asíncrona. El proceso de pago registra el pedido en la base de datos principal y publica un evento. Un worker en segundo plano recoge el evento y crea la orden de salida en GreaterWMS. Los fallos del worker se reintentan con una espera exponencial entre reintentos y generan una alerta si persisten. Este desacoplamiento es imprescindible.
Sincronización de pedidos
La llamada para crear una orden de salida recibe un ID de producto, una cantidad y la dirección de destino. La correspondencia entre las líneas de los pedidos de comercio electrónico y los ID de productos del WMS debe mantenerse de forma explícita. Guardamos el ID de producto del WMS como un campo adicional de cada variante en nuestra base de datos del catálogo. Esta correspondencia se establece manualmente al crear un producto y se comprueba en el worker de sincronización antes de enviar la solicitud de creación de la orden de salida.
La sincronización de estados funciona en sentido inverso: GreaterWMS actualiza el estado de la orden de salida a medida que el almacén la procesa, y el sistema de comercio electrónico debe reflejar esos cambios. GreaterWMS no envía los cambios de estado automáticamente; hay que consultarlos periódicamente. Ejecutamos una tarea cada pocos minutos que consulta las órdenes de salida con estado «in progress» y comprueba si ha cambiado a «dispatched» o «cancelled». Cuando ocurre, actualizamos el pedido correspondiente en nuestra base de datos de comercio electrónico y activamos las acciones posteriores: correos de notificación al cliente y actualizaciones del número de seguimiento.
La idempotencia es importante al crear órdenes de salida. Si el worker en segundo plano reintenta una operación tras un fallo transitorio, no debe crear órdenes duplicadas en GreaterWMS. Guardamos el ID de la orden de salida del WMS en nuestro registro interno del pedido inmediatamente después de una llamada de creación exitosa. Antes de volver a llamar al servicio de creación, el worker comprueba si ya existe un ID del WMS. Si existe, omite la creación y continúa con la acción posterior que estaba intentando ejecutar. Esta comprobación no cubre una llamada de creación que se completa correctamente en GreaterWMS, pero cuya respuesta se pierde antes de guardar el ID; en esos casos sigue siendo necesario realizar un cotejo con el WMS antes de reintentar.
Actualizaciones de inventario
Mantener sincronizadas las cantidades de inventario del comercio electrónico con el WMS es la parte que requiere más atención continua. Hay dos sentidos: la plataforma de comercio electrónico necesita niveles de existencias precisos para evitar vender más unidades de las disponibles, y el WMS debe reflejar las compras y devoluciones que se originan fuera de él.
Para consultar los niveles de existencias, obtenemos instantáneas de la API de inventario de GreaterWMS de forma programada y guardamos las cifras en una caché de Redis que consulta la tienda en línea. El intervalo de consulta depende del ritmo de ventas. Para productos de baja rotación, una consulta por hora es suficiente. Para productos que se venden en ráfagas, hace falta un intervalo más corto o un modelo de reserva, en el que añadir un artículo al carrito reserve temporalmente las existencias, con independencia del ciclo de sincronización del WMS.
Las devoluciones son el caso más complejo. Un artículo devuelto puede volver al inventario, pasar a una ubicación de cuarentena para su inspección o darse de baja. GreaterWMS dispone de un flujo de órdenes de entrada para devoluciones, pero relacionar los estados de devolución del comercio electrónico con los estados de las órdenes de entrada del WMS exige un diseño explícito. Creamos una máquina de estados que traduce los códigos de motivos de devolución del comercio electrónico a códigos de decisión sobre el destino de los artículos en el WMS, y revisamos la correspondencia con el equipo del almacén cada vez que se añade un motivo. Sin ella, las existencias devueltas dejan de aparecer en el inventario disponible sin que se detecte.
Condiciones de carrera y existencias de reserva
Incluso con una sincronización de inventario basada en consultas periódicas, pueden producirse condiciones de carrera. Si llegan dos pedidos a la vez y ambos leen el mismo nivel de existencias en caché antes de que alguno se refleje en el WMS, se pueden vender de más tantas unidades como se vendan durante el intervalo entre consultas. Para productos en los que esto sea inaceptable —artículos de edición limitada o perecederos con restricciones estrictas por lote—, la solución adecuada es una capa de reservas que reduzca el recuento local de unidades disponibles durante el proceso de pago y lo concilie con el WMS de forma asíncrona.
Una medida más sencilla consiste en mantener existencias de reserva: el recuento disponible en la base de datos del comercio electrónico equivale al nivel de existencias del WMS menos una pequeña reserva. Los pedidos consumen este margen. Cuando llega a cero, el producto aparece como agotado aunque el WMS aún muestre unidades. Esto introduce un pequeño riesgo de retener existencias que los clientes no pueden pedir, pero reduce el riesgo de vender más unidades de las disponibles y no requiere lógica de reservas. Para la mayoría de las pequeñas operaciones, es la opción más equilibrada.
Cuándo conviene un WMS frente a las hojas de cálculo
Un sistema de gestión de almacenes añade complejidad de integración, carga operativa y un nuevo sistema que mantener. Antes de comprometerse con una integración, conviene evaluar con franqueza si los problemas que se quieren resolver realmente requieren un WMS.
Las hojas de cálculo son suficientes cuando el número de SKU es pequeño y estable, hay un único almacén o centro de preparación de pedidos, los pedidos se procesan manualmente y el volumen es bajo, y no se necesita información en tiempo real sobre la cantidad disponible para comprometer en pedidos durante el proceso de pago. En ese caso, construir y mantener una integración de WMS cuesta más que los problemas que resuelve.
Un WMS empieza a compensar cuando hay varios almacenes o ubicaciones de preparación de pedidos, se necesita seguimiento de lotes por razones de cumplimiento normativo o calidad, la tasa de devoluciones exige gestionar sistemáticamente el destino de los artículos devueltos, o el procesamiento de pedidos está automatizado y requiere reservas precisas de existencias para evitar vender más unidades de las disponibles. Son problemas operativos que las hojas de cálculo no pueden resolver con un nivel razonable de rigor.
La integración que describimos en este artículo requirió varias semanas de trabajo de ingeniería, incluidas las pruebas. Ese tiempo habría podido financiar una cantidad considerable de trabajo manual de coordinación del almacén. Antes de empezar, defina con precisión qué problemas quiere resolver y si el software es la herramienta adecuada.