Cómo sincronizar productos, stock y pedidos entre tu ERP y tu ecommerce
Guía práctica para conectar ERP y tienda online: qué datos sincronizar y en qué sentido, quién manda cuando discrepan, qué frescura necesita cada dato y los errores que hunden estas integraciones.
Respuesta corta: se sincroniza cada dato en un solo sentido, con el ERP como fuente de verdad de catálogo, precios, stock y clientes, y la tienda como origen únicamente de lo que nace en ella (el pedido, el registro del cliente web). Cada dato necesita una frescura distinta — el stock, minutos; el catálogo, una vez al día — y toda la integración necesita tres cosas que casi nadie pone: validación antes de aplicar, registro de cada ejecución y avisos cuando algo no cuadra.
El punto de partida típico
Si tu tienda y tu ERP no están conectados, la operativa suele ser esta: alguien exporta el catálogo del ERP, lo retoca en Excel y lo sube a la tienda; el stock de la web «más o menos» coincide con el real; y cada pedido online se teclea a mano en el ERP. Funciona — hasta que un cliente compra algo agotado, un precio antiguo se queda publicado o la persona que sabe hacer las importaciones se va de vacaciones.
Sincronizar no es un lujo técnico: es quitarle a tu equipo el papel de mensajero entre dos sistemas.
Paso 1 — Decide qué viaja y en qué sentido
El error más común es pensar en «conectar los sistemas» en abstracto. Se conectan flujos de datos concretos, y cada uno tiene un sentido natural:
| Dato | Sentido | Por qué |
|---|---|---|
| Productos y catálogo | ERP → tienda | El ERP es donde se da de alta y se gestiona |
| Precios y tarifas | ERP → tienda | La política comercial vive en el ERP |
| Stock | ERP → tienda | El almacén real lo controla el ERP |
| Pedidos | Tienda → ERP | Nacen en la web, se administran en el ERP |
| Clientes nuevos (web) | Tienda → ERP | Nacen en la web… |
| Datos de cliente (condiciones, tarifas) | ERP → tienda | …pero sus condiciones las manda el ERP |
| Estados del pedido (enviado, facturado) | ERP → tienda | La administración informa a la web |
Los flujos bidireccionales «de verdad» son raros y caros: casi todo lo que parece bidireccional son dos flujos unidireccionales bien definidos.
Paso 2 — Nombra la fuente de verdad (y respétala)
Cuando ERP y tienda discrepen — y discreparán — ¿qué sistema tiene razón? La regla que casi siempre funciona: el ERP manda en catálogo, precios, stock y clientes; la tienda manda solo en lo que nace en ella. Escribirlo y respetarlo evita el clásico bucle donde cada sistema machaca los datos del otro y nadie sabe ya cuál era el bueno.
Corolario práctico: no edites en la tienda lo que el ERP gobierna. Si el precio se corrige en la web «un momento», la siguiente sincronización lo pisará — y debe pisarlo.
Paso 3 — Ponle frescura a cada flujo (no «tiempo real» a todo)
El tiempo real es más caro de construir y mantener, y casi nunca hace falta en todo:
- Stock: minutos. Es el dato que más duele desactualizado (vender lo que no hay).
- Pedidos: al confirmarse, o en ventanas de pocos minutos.
- Precios: varias veces al día suele bastar; al momento si hay ofertas relámpago.
- Catálogo (altas, descripciones, imágenes): una vez al día, de noche.
- Estados de pedido: en cada cambio o cada pocos minutos.
Decidir la frescura por flujo abarata la integración y la hace más robusta. Y sobre qué vía técnica usar para cada flujo — API, lectura de datos, ficheros validados — depende de lo que cada sistema exponga: lo desarrollamos en API REST o acceso directo a base de datos.
Paso 4 — Lo que separa una integración seria de un script
Mover datos es la parte fácil. Lo que evita los sustos es lo de alrededor:
- Validación antes de aplicar: referencias que existen, precios coherentes, formatos correctos. Lo que no pasa la validación, no entra.
- Cuarentena de registros problemáticos: el producto con datos rotos se aparta y se notifica; no tumba la sincronización de los otros mil.
- Registro de cada ejecución: qué se movió, cuándo, con qué resultado. Cuando algo no cuadre, la respuesta está en el log.
- Avisos concretos: «estas 3 referencias no existen en el ERP» en lugar de un fallo genérico a las 3 de la mañana que nadie ve.
- Idempotencia: si una sincronización falla a mitad, se relanza sin duplicar nada.
Es exactamente el enfoque que aplicamos en este proyecto donde las importaciones manuales desaparecieron del calendario semanal.
Los errores que hunden estas integraciones
- Sobrevender por stock viejo. Frescura de horas en el dato que necesitaba minutos. Resérvale al stock la mejor frecuencia de toda la integración.
- El bucle de la doble escritura. Dos sistemas escribiendo el mismo dato sin fuente de verdad definida. Se detecta tarde y se arregla caro.
- Duplicar pedidos o clientes por reintentos sin control: la idempotencia no es opcional.
- Machacar el ERP en horario de oficina con sincronizaciones masivas: las cargas gordas, de noche; el ERP tiene usuarios reales.
- El silencio. La integración que falla sin avisar es peor que no tener integración: los datos envejecen y todo el mundo confía en ellos. Si falla, que grite.
- Empezarlo todo a la vez. Empieza por el flujo que más duele — casi siempre pedidos o stock —, estabilízalo y amplía. Confianza primero, cobertura después.
¿Y si mi ERP es antiguo y «no se conecta»?
Casi ningún ERP «no se conecta»: la mayoría de los veteranos tienen mecanismos de importación/exportación validados, y para leer siempre hay caminos. La vía cambia; el patrón (sentidos, fuente de verdad, frescura, validación) es el mismo. Lo contamos a fondo en cómo integrar un ERP con una aplicación web.
¿Tu tienda y tu ERP siguen conectados por una persona con Excel? Cuéntanos qué sistemas usáis y te proponemos los flujos, la frescura y la vía para cada uno. Cuéntanos qué necesitas conectar →
Servicio relacionado: Integraciones y automatización
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Desarrollador fullstack con más de una década construyendo software para empresas. En MUROSOFT analiza el proceso antes que la tecnología: qué se hace hoy, qué cuesta y qué merece la pena automatizar. Trabaja de forma directa con quien va a usar el sistema, sin capas intermedias entre el problema y quien lo resuelve.