Por qué tu stock nunca cuadra entre el ERP y la tienda online

Un cliente compra a las 19:40 el último par de zapatillas del 42. A las 19:12 alguien se había llevado ese mismo par de la tienda de Bilbao. El TPV lo registró bien, el ERP lo registró bien, y la web tardó 34 minutos en enterarse. Ahora tienes un pedido cobrado, un producto que no existe y una llamada que hacer.

Esto no es un fallo. Es el comportamiento normal de casi cualquier montaje de comercio electrónico conectado a un ERP. La pregunta no es si te va a pasar, sino cada cuánto y cuánto te cuesta. Y sobre todo: cuánto estás dispuesto a pagar para que pase menos.

El stock no es un número, son cuatro números distintos

El primer malentendido es pensar que existe "el stock" de una referencia. En cualquier negocio con más de un canal hay al menos cuatro cifras que conviven y casi nunca coinciden:

• Stock físico: lo que hay en la estantería ahora mismo. Nadie lo sabe con exactitud sin contarlo.
• Stock contable: lo que dice el ERP. Depende de que las entradas, salidas, mermas y regularizaciones se hayan metido a tiempo.
• Stock disponible para vender: el contable menos lo reservado por pedidos aceptados, carritos activos, transferencias entre tiendas y material apartado para un cliente.
• Stock publicado: el número que ve el cliente en la ficha de producto. Es una copia, hecha en algún momento del pasado, del disponible.

El descuadre vive entre el tercero y el cuarto. Y crece con dos variables: la frecuencia con la que actualizas y la velocidad a la que vendes esa referencia concreta.

Sincronización por lotes: por qué te miente y por qué se usa igual

Lotes (o batch) significa que un proceso automático se despierta cada X minutos, pregunta al ERP el stock de todos los productos y lo vuelca a la tienda. Es lo que lleva montado el 80 % de las tiendas españolas conectadas a un Sage, un Navision, un A3 o un Odoo, y hay razones sensatas para ello: es barato, es fácil de depurar y si un día falla lo relanzas y se arregla solo.

El problema es que ese proceso tiene un coste de tiempo que casi nadie mide. Leer 3.000 referencias del ERP, compararlas y escribir los cambios en la tienda puede tardar entre 2 y 15 minutos según cómo esté hecho. Si programaste el cron —la tarea automática que lanza el proceso— cada 15 minutos y el proceso tarda 12, estás encadenando ejecuciones. Y cuando una tarda 20 porque el ERP está haciendo el cierre del día, se solapan dos procesos escribiendo lo mismo. Ahí es donde aparecen los descuadres raros: productos que vuelven a tener stock sin motivo, o que se quedan a cero y no se recuperan hasta el día siguiente.

Síntomas típicos de que tu lote está al límite:

• El descuadre aparece siempre a las mismas horas (mediodía, cierre, lunes por la mañana).
• Empeoró cuando metiste 800 referencias nuevas, aunque nadie tocó nada.
• Cuando hay campaña, se rompe. Justo el día que no puede romperse.

Casi siempre se puede arreglar sin cambiar de arquitectura: enviar solo los productos que han cambiado desde la última pasada en vez de los 3.000, priorizar las referencias de alta rotación con una frecuencia distinta, y separar la sincronización de stock de la de precios y descripciones. Eso solo ya suele bajar el tiempo de proceso a menos de la mitad. No elimina la ventana ciega, pero la estrecha bastante y cuesta días de trabajo, no meses.

Las reservas: el descuadre que no viene del ERP

Aquí está la parte que sorprende. Muchos descuadres no tienen nada que ver con la sincronización, sino con quién decide que una unidad ya no está disponible.

Ejemplos que se repiten en cualquier tienda con volumen:

• Carritos abiertos. ¿Reservas stock cuando alguien mete el producto en el carrito, o cuando paga? Si reservas al meter, te quedas sin vender por carritos abandonados. Si reservas al pagar, dos clientes pueden completar la compra de la misma unidad con segundos de diferencia.
• Pagos en curso. Una transferencia o un Bizum con confirmación diferida deja el pedido en el aire. ¿Ese producto está vendido o no?
• Pedidos que el ERP aún no ha "visto". Si el pedido web entra en el ERP cada hora, durante esa hora el ERP cree que tiene stock que ya está comprometido. Y como el ERP es la fuente de la verdad, en la siguiente sincronización le devuelve a la web un número inflado. El sistema se corrige a sí mismo hacia el error.
• Apartados en tienda física. El dependiente guarda un abrigo para una clienta que vuelve el sábado. Eso no existe en ningún sistema. Existe en un post-it.
• Transferencias entre tiendas. Salió de Valencia el martes, llega a Sevilla el jueves. Durante 48 horas está en un limbo contable que, según cómo esté configurado el ERP, puede aparecer como disponible en los dos sitios o en ninguno.

El último punto es el que más duele en cadenas. Si tienes seis puntos de venta y vendes online contra el stock consolidado, cada transferencia es una oportunidad de vender aire. Ese caso concreto —unificar el stock de tienda física y web en un solo número fiable— tiene bastante más miga y lo tratamos aparte en cómo se hace de verdad un stock único entre TPV y tienda online.

Devoluciones: el stock que vuelve tarde y a veces no vuelve

Una devolución es una entrada de stock que pasa por cuatro manos antes de ser real: transportista, recepción, revisión de estado y alta en el ERP. Entre que el cliente inicia la devolución y que ese producto vuelve a estar publicado pueden pasar de 3 a 10 días laborables en un almacén propio con procesos normales.

Durante esos días tienes un producto que existe, está pagado por nadie y no se puede vender. En moda, con tasas de devolución que en algunas categorías rondan el 20-30 %, eso significa una parte nada despreciable de tu inventario congelada de forma permanente. No es un fallo de sincronización: es un fallo de proceso que la sincronización te está fotografiando fielmente.

Y hay una versión peor: la devolución que se da de alta en el ERP dos veces, o que se da de alta pero el producto acabó en la caja de "revisar" y nunca volvió a la estantería. Ese es stock fantasma, y es el que te hace prometer entregas que no puedes cumplir.

Lo que cuesta de verdad

El coste visible de vender lo que no tienes es la devolución del dinero. Ese es el barato. Lo caro está debajo:

El último es el que más se subestima. Si el feed de producto que alimenta tus campañas de Shopping se genera del mismo sistema descuadrado, estás pagando clics hacia fichas sin stock. Y no es solo dinero: es tráfico que aterriza en una página que no convierte y que le dice al algoritmo que ese producto no funciona.

El descuadre de stock no es un problema técnico con consecuencias comerciales. Es un problema comercial que se manifiesta en la técnica.

Tres formas de arreglarlo, con sus pegas

1. Afinar el lote que ya tienes

Mandar solo los cambios, subir la frecuencia en las referencias calientes, y añadir un colchón de seguridad: publicar cero cuando queden menos de 2 o 3 unidades en las referencias de alta rotación. Dejas de vender algunas unidades reales a cambio de dejar de vender unidades fantasma.

Cuándo gana: facturas menos de 100.000-150.000 al mes online, un solo almacén, y tus descuadres son puntuales. Coste típico: días de trabajo, no un proyecto.
Cuándo no: si vendes piezas únicas, alta rotación o marketplaces exigentes, el colchón te come el catálogo entero.

2. Pasar a eventos: que el ERP avise cuando algo cambia

En vez de preguntar cada 15 minutos, el ERP (o el TPV) lanza un aviso en el momento exacto en que se mueve una unidad y la tienda se actualiza en segundos. Se hace con webhooks —una llamada automática de un sistema a otro cuando pasa algo— o con una cola de mensajes que garantiza que ningún aviso se pierde aunque la web esté caída dos minutos.

Esto exige que tu ERP sepa hacerlo. Muchos ERP españoles de hace diez años no lanzan eventos, y hay que sacarlos leyendo la base de datos o con un desarrollo del fabricante que se factura aparte. Aquí es donde suele aparecer la palabra API en el presupuesto, y conviene entender qué te están cobrando exactamente.

Cuándo gana: un canal principal, un ERP moderno o con API decente, y descuadres que ya cuestan más que el proyecto.
Cuándo no: si tienes cinco sistemas hablando entre sí, montar eventos punto a punto entre todos crea una maraña peor que la que tenías. Cada nueva integración multiplica las conexiones.

3. Una capa intermedia que sea la dueña del stock

Un sistema en medio que recibe todos los movimientos —ERP, TPV de las seis tiendas, web, marketplaces, logística— mantiene el disponible real con sus reservas, y publica hacia cada canal. El ERP deja de ser la fuente de verdad del disponible y pasa a ser la fuente de verdad del contable, que es lo suyo.

Es la solución correcta cuando hay varios canales, pero es un proyecto de verdad: semanas o meses, un sistema más que mantener y vigilar, y alguien que entienda cómo funciona cuando falle a las nueve de la mañana de un Black Friday. Está desarrollado en detalle en qué es un middleware y cuándo lo necesitas.

Cuándo gana: tres o más canales, varias ubicaciones físicas, o un roadmap con más canales por venir.
Cuándo no: un solo almacén y un solo canal. Ahí es sobreingeniería cara.

Lo que ninguna de las tres arregla

Ninguna arquitectura corrige un inventario que no cuadra en el almacén. Si tu inventario contable tiene una desviación del 3 % respecto al físico, sincronizar en tiempo real solo hace que el error viaje más rápido. El orden correcto es: primero inventario fiable, después reglas claras de reserva y devolución, y solo entonces la fontanería técnica.

Y hay una decisión de negocio previa que no es de sistemas: qué prefieres, perder ventas por ser conservador o perder clientes por vender aire. No existe la configuración que evite las dos cosas. Existe el punto en el que decides cuánta de cada una aceptas, y ese punto lo pones tú, no el integrador.