Ecommerce
Sincronizar el stock de tu ERP con la tienda online: lo que falla de verdad
Conectaste relBase, Bsale o Defontana con tu tienda, la integración dice que está activa, y aun así hay productos con el stock descuadrado. La conclusión intuitiva es «la integración no funciona». Casi nunca es eso. En la práctica son tres cosas muy concretas, y las tres se comprueban en minutos.
Esto está escrito desde integraciones en producción con ERP chilenos, con los detalles que no vienen en la documentación de nadie.
1. La llave es el SKU, y si falta el producto queda congelado
Toda integración de stock empareja productos por un campo, y en los ERP chilenos ese campo es el código del producto contra el SKU de la tienda. No el nombre. No el código de barras. No el identificador interno.
Lo que pasa cuando el SKU está vacío o es distinto es lo peor posible: el producto no da error, se congela. Queda publicado con el último stock que alguien escribió a mano, invisible para la sincronización, vendiéndose sin que nadie lo descuente. Y como la integración sigue informando «activa», nada te avisa.
Por eso ante cualquier descuadre, el primer paso es siempre el mismo:
- ¿Ese producto tiene SKU en la tienda?
- ¿Coincide exactamente con el código del ERP, sin espacios ni guiones extra?
- ¿Hay dos productos activos con el mismo SKU?
Lo tercero es más común de lo que parece, sobre todo con variantes, y produce un descuadre que parece aleatorio: la sincronización escribe en uno de los dos y el otro queda viejo.
Si tu catálogo nace en el ERP, créalo ahí primero. Es la forma más simple de garantizar que los códigos coincidan: el SKU de la tienda se rellena desde el ERP y no desde la memoria de quien carga el producto.
2. Estás comparando contra la bodega equivocada
Esta es la que más tiempo hace perder, porque todo parece correcto y los números no cuadran igual.
Si tu empresa tiene más de una bodega, el ERP te muestra en pantalla un stock total —la suma de todas— pero la tienda se alimenta de una sola. En un caso que operamos, el ERP tenía tres bodegas con miles de códigos cada una y la web se alimentaba de una sola de ellas. El campo «disponible» que aparece en el inventario era la suma de las tres, y no era lo que mostraba la tienda. Comparar contra ese total hacía ver descuadres en todos los productos a la vez.
Averigua qué bodega alimenta la web y compara siempre contra esa. Si no lo sabes, está en la configuración de la integración, y conviene anotarlo donde lo encuentre el próximo que revise.
Hay además un detalle técnico que muerde a quien consulta la API directamente: el
stock por bodega suele venir como una lista de cadenas con el formato
"bodega,cantidad" —por ejemplo "6198,79"— y no como
números separados. El campo que parece «el stock» a secas es el agregado. Si tomas
ese, estás leyendo otra cosa.
3. El ERP sincroniza stock, pero no crea productos
Es una expectativa equivocada muy extendida. La integración actualiza el stock de los productos que ya existen en los dos lados. No publica el catálogo.
En el caso que mencionamos, el ERP tenía alrededor de 6.350 códigos y la tienda publicaba 248. Eso no es un fallo: es la decisión correcta, porque la mayoría del catálogo de un distribuidor no tiene sentido publicarlo. Pero significa que cada producto nuevo que quieras vender online hay que crearlo a mano en la tienda, con el código exacto en el SKU. Si se crea sin SKU, nace congelado —volvemos al punto 1.
Conviene que eso sea un paso explícito del procedimiento de quien carga productos, no algo que se recuerde a veces.
Las trampas de las APIs chilenas, si lo haces a mano
Si en vez de un plugin estás programando la integración, hay cosas que cuestan una tarde descubrir.
Los parámetros de paginación pueden ser decorativos
Nos encontramos con una API que ignora silenciosamente per_page
y search: devuelve siempre 12 resultados por página, haga lo
que pidas. No da error, simplemente no obedece. Para buscar un producto hay que
bajar el inventario completo —cientos de páginas, varios minutos— y filtrar en casa.
Si tu integración necesita buscar en vivo, eso cambia el diseño entero: toca
cachear.
El refresh token rota en cada uso
Esta es la que puede dejarte fuera. En los ERP que usan OAuth, cada vez que refrescas el acceso el refresh token anterior se invalida y te entregan uno nuevo. Consecuencia práctica: no puede haber dos copias vivas del archivo de credenciales, ni dos procesos refrescando a la vez. El segundo recibe un 403 y el token se pierde para los dos — hay que volver a autorizar a mano.
Esto pasa más de lo que parece cuando el archivo de credenciales está dentro de una carpeta sincronizada en la nube, porque el respaldo crea una segunda copia que parece válida. Guarda las credenciales fuera de cualquier carpeta sincronizada, y que un solo proceso tenga permiso para refrescar.
El stock por webhook llega cuando llega
Las integraciones buenas empujan el cambio cuando se mueve el stock, no cada hora. Eso es mejor, pero significa que un producto puede pasar días sin actualizarse simplemente porque nadie lo vendió — y eso no es un fallo. Antes de declarar roto algo, mira si hubo movimiento.
La única solución que funciona a largo plazo: auditar
Una integración de stock es de esas cosas que se rompen sin avisar. Un producto creado sin SKU, un código cambiado en el ERP, una variante duplicada: ninguna de las tres da error. Simplemente, de a poco, el catálogo se va desalineando.
Lo que recomendamos y lo que dejamos instalado en los proyectos es una auditoría automática semanal que revise tres cosas y avise si alguna falla:
- Productos activos sin SKU o con SKU duplicado.
- SKU publicados que no existen en el ERP (código cambiado o producto dado de baja).
- Diferencia de stock entre la bodega que alimenta la web y lo publicado, por encima de un margen que tú decidas.
Son tres consultas. Corriendo un día fijo a la semana y avisando solo cuando hay algo, convierten un problema que se descubre con un cliente enojado en un correo de lunes por la mañana.
Si tienes la tienda descuadrada y no sabes por dónde empezar, lo revisamos: el diagnóstico es justamente esas tres consultas, y normalmente deja claro el mismo día si el problema son SKU, bodegas o la integración.
Dudas frecuentes
¿Por qué un producto no actualiza su stock aunque la integración esté activa?
En la gran mayoría de los casos, porque su SKU está vacío o no coincide exactamente con el código del ERP. El producto no da error: queda congelado con el último stock que alguien escribió a mano, y se sigue vendiendo sin descontarse. La segunda causa más común es un SKU duplicado entre dos productos activos, que hace que la sincronización escriba en uno y deje el otro viejo.
¿El ERP crea los productos en mi tienda?
No. Las integraciones de stock actualizan productos que ya existen en los dos lados; no publican el catálogo. Es lo correcto, porque la mayoría del catálogo de un distribuidor no tiene sentido publicarlo, pero implica que cada producto nuevo hay que crearlo a mano en la tienda con el código exacto en el SKU. Si se crea sin SKU, nace invisible para la sincronización.
El stock del ERP y el de la web no coinciden. ¿Está roto?
Probablemente no. Si tienes varias bodegas, el ERP te muestra el total y la tienda se alimenta de una sola, así que comparar contra el total hace ver descuadres en todos los productos a la vez. Averigua cuál bodega alimenta la web y compara contra esa. Si usas la API directamente, revisa además que estés leyendo el stock por bodega y no el campo agregado.
¿Cada cuánto se sincroniza el stock?
Las integraciones modernas lo empujan cuando el stock se mueve, no en un horario fijo. Eso es mejor que un proceso cada hora, pero significa que un producto puede pasar días sin cambios simplemente porque nadie lo vendió. Antes de dar por roto algo, comprueba si hubo movimiento de ese código en el periodo.
¿Cómo evito que la integración se rompa sin que nadie se entere?
Con una auditoría automática semanal que revise tres cosas: productos activos sin SKU o con SKU duplicado, SKU publicados que ya no existen en el ERP, y diferencias de stock entre la bodega que alimenta la web y lo publicado. Ninguno de esos tres fallos produce un error, así que sin una revisión programada el catálogo se desalinea de a poco hasta que lo descubre un cliente.