Stock en tiempo real entre e-commerce, ERP y tiendas físicas

Vender el mismo producto por tres canales a la vez parece un problema de negocio. En realidad es un problema de sistemas distribuidos: tres sistemas, cada uno con su propia idea de cuántas unidades quedan, y un cliente que no quiere oír “lo sentimos, al final no lo teníamos”.

Este es el caso de cómo sincronizamos el stock en tiempo real entre una tienda online, un ERP y las tiendas físicas de un retailer, siendo el equipo técnico responsable de las tres piezas.

Contexto

El negocio vendía por tres vías:

Canal	Sistema	Quién lo controlaba
Tienda online	E-commerce	Nosotros
Gestión, compras y almacén	ERP	Un proveedor externo
Tiendas físicas	TPV (punto de venta)	Nosotros: lo construimos a medida

El TPV lo desarrollamos desde cero con Vue.js y PHP, pensado para las tiendas del propio negocio. Eso nos dio una ventaja importante: dos de los tres sistemas eran nuestros y podíamos decidir cómo se comunicaban.

El tercero, el ERP, no. Tenía su propio modelo de datos, sus propios tiempos y sus propias reglas. Como casi todos los ERPs, no se diseñó pensando en el tiempo real.

El problema de fondo: ¿quién manda?

Antes de hablar de colas o de APIs, hay una pregunta que lo decide todo: ¿cuál es la fuente de verdad del stock?

Si cada sistema cree que es él, el resultado es predecible:

• Una venta online descuenta stock en el e-commerce, pero el ERP no se entera hasta más tarde.
• Mientras tanto, una tienda física vende la última unidad del mismo producto.
• Llega una reposición al almacén que el ERP registra, pero el e-commerce sigue mostrando “agotado”.

Cada sistema tiene razón con la información que tiene. El problema es que ninguno la tiene completa.

Hay varias formas de resolverlo, cada una con sus costes:

Enfoque	Ventaja	Coste
El ERP es la única verdad y todos le preguntan	Un solo sitio que mirar	Cada venta depende de que el ERP responda rápido y esté disponible
Cada canal tiene su stock y se reconcilia periódicamente	Canales independientes	Ventanas de desfase donde se puede vender lo que no hay
El ERP es la verdad, pero cada movimiento se propaga como evento	Casi tiempo real sin acoplar cada venta al ERP	Más piezas: colas, reintentos, idempotencia

Diseño

La idea central es dejar de pensar en “el stock” como un número que se copia de un sitio a otro, y empezar a pensar en movimientos de stock: una venta online, una venta en tienda, una devolución, una entrada de mercancía. Cada movimiento es un hecho que ocurre en un sistema y que los demás necesitan conocer.

  Venta online ─┐                       ┌─▶ E-commerce (stock visible)
  Venta en TPV ─┼─▶ movimiento de stock ─┼─▶ ERP (contabilidad, compras)
  Reposición ───┘   (cola + reintentos)  └─▶ TPV de cada tienda

Movimientos, no números

Propagar “quedan 3 unidades” es frágil: si dos mensajes llegan desordenados, el número final es incorrecto. Propagar “se ha vendido 1 unidad” es más robusto, siempre que cada movimiento se aplique una sola vez. Por eso cada movimiento necesita un identificador único, y quien lo recibe tiene que poder ignorar los duplicados.

El ERP, detrás de una cola

El ERP no puede estar en el camino crítico de una venta. Si tarda o no está disponible, la tienda online y los TPV tienen que seguir vendiendo. Por eso la comunicación con el ERP va desacoplada: los movimientos se encolan y se envían con reintentos. Si el ERP cae, los movimientos esperan; cuando vuelve, se procesan en orden.

Conflictos y sobreventa

Con tres canales vendiendo en paralelo, la sobreventa no se puede eliminar del todo; solo se puede hacer improbable y tener un plan para cuando ocurra. Las palancas habituales son:

• Reducir la ventana de desfase, propagando los movimientos en cuanto ocurren.
• Márgenes de seguridad en productos con pocas unidades, mostrando “agotado” online un poco antes.
• Reservas: descontar stock al empezar el pago, no al terminarlo.
• Un proceso claro para cuando, aun así, se vende algo que no hay.

Herramientas para el catálogo

Sincronizar stock solo funciona si los tres sistemas hablan del mismo producto. Una parte del trabajo, menos vistosa, fueron las herramientas en PHP y Node.js para crear y mantener el catálogo, tanto online como offline. Si las referencias no cuadran entre sistemas, ninguna arquitectura de eventos lo arregla.

Resultado

El resultado fue un stock en tiempo real entre la tienda online, el ERP y las tiendas físicas, con un TPV propio que formaba parte de la misma arquitectura en lugar de ser una isla.

Lo que cambiaría hoy

La arquitectura respondía bien a los problemas que teníamos. Con lo que sé ahora, cambiaría algunas cosas:

• Un registro de movimientos como fuente de verdad interna, del que el stock de cada canal sea una proyección. Facilita auditar qué pasó y reconstruir el estado si algo se corrompe.
• Más observabilidad sobre el desfase: saber en cada momento cuánto va por detrás cada sistema, y avisar si la cola con el ERP crece.
• Reconciliación automática periódica entre sistemas, para detectar diferencias antes de que las detecte un cliente.

Lo que aprendí

La pregunta importante no es técnica. “¿Quién es la fuente de verdad?” se responde con el negocio: quién compra, quién vende y quién responde si los números no cuadran. La arquitectura viene después.

Propaga hechos, no estados. Los movimientos se pueden ordenar, deduplicar y volver a aplicar. Los números copiados de un sitio a otro, no.

Desacopla lo que no controlas. El ERP era el sistema más importante y el que menos controlábamos. Ponerlo detrás de una cola permitió que sus problemas no fueran problemas de la tienda.

Construir el TPV fue una decisión de arquitectura. Tener el punto de venta en casa no era solo cuestión de funcionalidades: permitió que el tercer canal hablara el mismo idioma que los otros dos.

Sincronizar stock parece una integración más. En realidad es uno de los problemas de consistencia más reales que hay en e-commerce, porque cuando sale mal, lo nota un cliente.