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 se suelen olvidar: 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 parecida. 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 sirve para quitarle a tu equipo el papel de mensajero entre dos sistemas.
Paso 1. Decide qué viaja y en qué sentido
Pensar en «conectar los sistemas» en abstracto lleva a error. Lo que se conecta son 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 puros 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)
ERP y tienda van a discrepar, así que hay que decidir qué sistema tiene razón. La regla que casi siempre funciona es que 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.
En la práctica, eso significa no editar 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, en 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 fiable. La vía técnica de cada flujo (API, lectura de datos, ficheros validados) depende de lo que exponga cada sistema, y 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. Que las referencias existan, los precios sean coherentes y los 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, sin tumbar la sincronización de los otros mil.
- Registro de cada ejecución, con qué se movió, cuándo y con qué resultado. Cuando algo no cuadre, la respuesta está en el log.
- Avisos concretos, del tipo «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.
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 van de noche, porque el ERP tiene gente trabajando en él.
- El silencio. La integración que falla sin avisar es peor que no tener integración, porque los datos envejecen mientras 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 desde ahí.
¿Y si mi ERP es antiguo y «no se conecta»?
Casi ningún ERP es incapaz de conectarse. La mayoría de los veteranos tienen mecanismos de importación/exportación validados, y para leer siempre hay caminos. La vía cambia, pero 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.
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Ingeniero informático y desarrollador de software para empresas, con más de una década construyendo sistemas de gestión, integraciones y aplicaciones. 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.