Conectar PrestaShop con Odoo: cómo se sincronizan stock, pedidos y catálogo
Cómo conectar PrestaShop con Odoo ERP para sincronizar stock, pedidos, clientes y catálogo en tiempo real: flujos, conector frente a integración a medida, conflictos y coste.
Autor y revisor: Jon González
Conectar PrestaShop con Odoo: la integración que elimina el copiar y pegar
Tienes una tienda en PrestaShop que vende bien y un ERP Odoo para la facturación y el almacén. Pero entre los dos hay una persona que cada mañana descarga los pedidos de la web y los teclea en Odoo, y que actualiza el stock de la tienda cuando entra mercancía.
Esa persona se equivoca, se pone enferma y se va de vacaciones. Y cuando llega el Black Friday y entran 500 pedidos, el sistema manual colapsa y los envíos salen tarde.
Conectar PrestaShop con Odoo significa que ambos sistemas se hablen solos, de forma continua: el stock, los pedidos, los clientes y el catálogo viajan de uno a otro sin intervención humana.
Respuesta corta: una integración PrestaShop–Odoo bien hecha sincroniza catálogo (Odoo → web), stock (en los dos sentidos) y pedidos y clientes (web → Odoo), con un sistema que manda sobre cada dato. Para una pyme, conectar la tienda con Odoo cuesta como orientación entre 800 y 2.500 €, según el número de flujos y de personalizaciones. Son los rangos de nuestro desglose de costes de implantar Odoo.
¿Todavía no tienes tus datos en Odoo? Este artículo trata de la conexión continua entre dos sistemas que ya funcionan. Si lo que necesitas es la carga inicial de productos, clientes e histórico, empieza por la guía para migrar PrestaShop a Odoo y vuelve aquí para la sincronización.
Qué se sincroniza y en qué sentido
| Dato | Sentido | Quién manda | Frecuencia habitual |
|---|---|---|---|
| Productos, precios y descripciones | Odoo → PrestaShop | Odoo | Al guardar en Odoo |
| Stock disponible | Odoo ↔ PrestaShop | Odoo | En tiempo real o cada pocos minutos |
| Pedidos | PrestaShop → Odoo | PrestaShop (origen) | Al confirmarse el pago |
| Clientes y direcciones | PrestaShop → Odoo | PrestaShop al crear; Odoo después | Con cada pedido |
| Estado del envío y tracking | Odoo → PrestaShop | Odoo | Al validar el albarán |
La regla de oro: cada dato tiene un único dueño. Si los dos sistemas pueden editar el mismo campo, tarde o temprano se pisan.
Arquitectura de la conexión
No usamos «conectores mágicos» de 50 €. Diseñamos integraciones robustas mediante la API de ambos sistemas.
Flujo 1: Catálogo (Odoo → web)
Odoo es el maestro. Creas el producto en Odoo, le pones precio, fotos y descripción. Al guardar, el conector envía esa información a PrestaShop. Si cambias el precio en Odoo, cambia en la web al instante. Ventaja: tu equipo administrativo no entra al panel de la tienda para nada. Trabaja solo en su ERP.
Flujo 2: Stock (Odoo ↔ web)
Es lo más crítico.
- Venta en tienda física (TPV de Odoo): se resta una unidad y Odoo avisa a la web: «quedan 4».
- Venta en la web: se resta una unidad y la web avisa a Odoo para reservarla. Odoo actualiza su stock disponible.
- Entrada de mercancía de proveedor: el almacén lee el código de barras en Odoo, el stock sube y la web muestra «En stock» automáticamente.
Adiós a vender lo que no tienes.
Flujo 3: Pedidos (web → Odoo)
El cliente paga en la web. Al instante, el pedido aparece en Odoo como pedido de venta confirmado:
- Se crea la ficha del cliente en Odoo si es nuevo, sin duplicarlo si ya existe.
- Se asigna el transportista correcto.
- Se genera el albarán de salida en el almacén.
El almacén ve en su tablet un pedido nuevo para preparar. Lo empaqueta, valida el albarán y Odoo envía el número de seguimiento a la web, que manda al cliente el email de «Enviado».
Todo esto sin que nadie en administración toque un papel.
Conector estándar o integración a medida
| Conector de la tienda de apps | Integración a medida por API | |
|---|---|---|
| Coste inicial | Bajo | Medio (800 – 2.500 € como orientación) |
| Encaje con tu operativa | El que traiga de serie | Se adapta a tus impuestos, estados y transportistas |
| Errores y reintentos | Depende del proveedor; a menudo silenciosos | Cola de reintentos y avisos cuando algo falla |
| Personalizaciones de PrestaShop | Suelen romperse con módulos de terceros | Se mapean una a una |
| Cuándo tiene sentido | Catálogo pequeño, sin variantes complejas ni TPV | Stock compartido con tienda física, varios almacenes o volumen alto |
Un conector estándar puede bastar para empezar. El problema aparece cuando falla en silencio: un pedido que no llega a Odoo no da error en ninguna pantalla, simplemente no se envía.
Gestión de conflictos
¿Qué pasa si un cliente compra el último artículo en la web justo cuando alguien lo compra en la tienda física? La integración gestiona bloqueos de registro y colas de prioridad, y siempre hay una fuente única de verdad para cada dato.
Los tres conflictos que hay que resolver antes de conectar nada:
- Duplicados de clientes: se decide por qué campo se reconoce a un cliente existente (email, NIF).
- Impuestos y estados de pedido: se mapean uno a uno entre PrestaShop y Odoo; un IVA mal mapeado descuadra la contabilidad.
- Fallos de red: cada mensaje que no se entrega se reintenta y, si sigue fallando, avisa a una persona.
El valor de los datos unificados
Con todo conectado, los informes por fin son reales:
- ¿Qué productos se ven mucho en la web pero no se compran?
- ¿Qué clientes compran online y en tienda física?
- ¿Cuál es el margen real de cada venta web, descontando los costes logísticos reales?
Implementación
Conectar PrestaShop con Odoo no es instalar un plugin: es un proyecto de ingeniería. Hay que mapear impuestos, estados de pedido, transportistas y categorías, y probarlo todo en un entorno de pruebas antes de activarlo. Una vez hecho, tu capacidad operativa deja de depender de las personas: el sistema procesa igual 10 pedidos diarios que 10.000.
Preguntas frecuentes sobre conectar PrestaShop con Odoo
¿Se puede conectar PrestaShop con Odoo sin cambiar de tienda?
Sí. Es el caso más habitual: PrestaShop sigue siendo el escaparate y Odoo pasa a gestionar stock, facturación y compras. La tienda, sus URL y su posicionamiento no cambian.
¿La sincronización es en tiempo real?
Los pedidos y el stock pueden viajar en tiempo real o con intervalos de pocos minutos. El catálogo suele enviarse al guardar el producto en Odoo. La frecuencia se ajusta a tu volumen para no saturar ninguno de los dos sistemas.
¿Qué diferencia hay entre conectar y migrar PrestaShop a Odoo?
Migrar es la carga puntual de datos (productos, clientes, histórico) en Odoo. Conectar es la sincronización continua una vez ambos sistemas funcionan. La mayoría de proyectos necesitan las dos cosas, en ese orden; la migración la explicamos en la guía para migrar PrestaShop a Odoo.
¿Qué pasa si la conexión falla?
Una integración bien hecha guarda cada mensaje pendiente, lo reintenta y avisa si no consigue entregarlo. Lo peligroso son los conectores que fallan en silencio.
¿Y ahora qué?
Si tu objetivo es escalar sin contratar a alguien para copiar pedidos, necesitas este puente. Te preparamos un presupuesto cerrado en 48 horas tras una llamada de diagnóstico de 30 minutos.
Ampliación editorial · revisión 2026
La decisión central de esta guía
¿Cómo se sincronizan Odoo y PrestaShop sin duplicar pedidos o stock?
Define Odoo o PrestaShop como maestro por entidad, usa identificadores persistentes, eventos o colas, idempotencia y estados de reconciliación. Producto, variante, precio, stock, cliente, pedido y devolución pueden seguir direcciones distintas; no existe un “sincronizar todo” seguro.
Empieza con catálogo o pedidos, no ambos. Prueba altas, cambios, borrados y reintentos. El stock disponible puede necesitar reservas y almacenes, no copiar una cifra. Define qué ocurre si un sistema no responde y quién resuelve.
Registra payload, versión, origen, destino, intento y resultado sin exponer secretos. Compara recuentos y muestras. Mide retraso, diferencias, duplicados y tiempo de resolución. Ejecuta carga y fallo controlado en staging.
Tiempo real añade coste y no siempre aporta valor. Los conectores estándar requieren validar personalizaciones. No edites bases directamente para reparar sin procedimiento: crea una operación reconciliable y auditable.
Marco técnico
Criterios para implantar e integrar un ERP sin perder control
Un ERP organiza procesos y datos compartidos entre ventas, compras, inventario, facturación y otras áreas. Implantarlo no es activar módulos: exige acordar responsables, limpiar información, configurar permisos, probar recorridos y formar al equipo para que el sistema represente la operación real.
La primera fase mapea procesos, documentos, excepciones y datos maestros. Cliente, producto, tarifa, stock y factura no pueden tener varias versiones correctas. Cada campo necesita origen, formato, propietario y regla de cambio. Migrar datos sucios a una herramienta nueva acelera el mismo problema.
La implantación por fases limita riesgo. Un recorrido como oportunidad, pedido y factura puede probar permisos, secuencia y adopción antes de añadir compras, almacén o producción. Activar todo crea dependencias difíciles de aislar y obliga a formar al equipo en procesos que todavía cambian.
Las integraciones trabajan con contratos. Identificador, entrada, salida, frecuencia, error y reconciliación se documentan. El tiempo real se reserva para decisiones que lo necesitan; colas y lotes suelen ofrecer mayor resiliencia. Los registros permiten explicar por qué un pedido no llegó sin editar directamente la base de datos.
El coste total incluye licencia, análisis, configuración, migración, personalización, integración, formación, soporte, infraestructura y actualizaciones. Un rango publicado puede orientar, pero solo un inventario permite presupuestar. La opción más barata al inicio puede depender de personalizaciones que encarezcan cada versión futura.
Lista de control antes de ejecutar
- 01Procesos aceptados
Responsables y usuarios validan el recorrido antes de configurarlo.
- 02Datos perfilados
Duplicados, vacíos, formatos e históricos se conocen antes de migrar.
- 03Permisos por función
Ver, crear, validar, cancelar y exportar se asignan por responsabilidad.
- 04Ensayos de migración
Se ejecutan cargas repetibles y se comparan saldos y recuentos.
- 05Go-live reversible
Ventana, copia, corte, soporte y decisión de rollback están acordados.
- 06Formación contextual
Cada rol practica sus tareas y excepciones con datos representativos.
Qué medir para saber si funciona
Mide exactitud de inventario, documentos con error, tiempo de ciclo, tareas fuera del sistema, incidencias por rol y adopción de recorridos críticos. El número de usuarios conectados no demuestra que el ERP sustituya hojas o decisiones informales.
Durante el arranque registra diferencias de migración, bloqueos, reintentos de integración y tiempo de resolución. Una implantación estable reduce excepciones gradualmente; ocultarlas para cumplir una fecha pospone el coste y deteriora la confianza del equipo.
Playbook propio de esta guía
Arquitectura reconciliable para pedidos, catálogo y stock
Esta ampliación desarrolla el problema específico de conectar prestashop con odoo: cómo se sincronizan stock, pedidos y catálogo y no se reutiliza en otras entradas del Laboratorio.
Asignar maestros por entidad
Decide quién crea y modifica producto, variante, precio, stock, cliente, pedido, envío y devolución. Puede haber direcciones distintas: Odoo publica catálogo y PrestaShop origina pedidos. Documenta identificadores persistentes y mapeos. No uses nombre o SKU mutable como única clave. “Sincronizar todo” oculta conflictos y crea bucles donde ambos sistemas se corrigen mutuamente.
Define estados y transiciones. Un pedido pagado, cancelado o reembolsado no es solo un registro. Especifica qué eventos viajan, orden y reacción ante llegada tardía. El stock disponible puede restar reservas y considerar almacenes; copiar existencias físicas provoca sobreventa. Alinea la fórmula y quién decide antes de escribir integración.
Entrega idempotente y observable
Cada mensaje lleva identificador, versión, origen y momento. Repetirlo no crea un segundo pedido. Usa cola o registro de estado para reintentar con límite. Valida payload y separa error temporal de dato inválido. No escribas secretos ni información personal completa en logs. Una alerta incluye entidad, intento, causa y acción para que soporte pueda resolver.
Prueba altas, cambios, borrados, paquetes, descuentos, impuestos, direcciones y devoluciones. Fuerza API lenta, caída y respuesta parcial. Ejecuta carga con volumen realista. Tiempo real solo se justifica por necesidad; un lote cada minutos puede ser más robusto y suficiente. Diseña degradación para que una tienda no confirme disponibilidad que ya no puede comprobar.
Reconciliación y despliegue
Construye informe que compare recuentos, importes, estados y muestras entre sistemas. Una ejecución verde no prueba corrección del dato. Define reparación mediante una operación auditable y evita editar bases directamente. Conserva el payload original y resultado para reproducir. La reconciliación es una función del producto, no una tarea temporal de puesta en marcha.
Despliega por entidad y en staging. Empieza lectura o catálogo, después pedidos y estados. Mantén rollback y evita activar dos conectores sobre las mismas entidades. Mide retraso, diferencias, duplicados e incidencias. Actualiza pruebas al cambiar versión de Odoo, PrestaShop o módulo. Una integración vive tanto como sus contratos externos.
Diseño de integración: pedidos, catálogo y stock sin ambigüedades
Una sincronización entre Odoo y PrestaShop empieza por decidir qué sistema manda en cada entidad. El catálogo puede nacer en el ERP mientras el contenido comercial se completa en la tienda; el stock suele depender del inventario; el pedido nace en ecommerce y evoluciona en el ERP. Estas reglas deben escribirse campo por campo, incluyendo variantes, impuestos, descuentos, direcciones y estados. Sin una propiedad clara, dos sistemas pueden sobrescribir el mismo dato o entrar en un bucle de actualizaciones. También se define una clave estable para relacionar registros: una referencia de negocio controlada o un identificador persistente, nunca una coincidencia frágil por nombre. El contrato de integración recoge formatos, valores permitidos, zona horaria y comportamiento cuando falta información.
La fiabilidad depende de tratar los fallos como parte normal del sistema. Cada mensaje necesita identificador, marca temporal y posibilidad de reintento sin duplicar pedidos o movimientos. Los errores se clasifican: dato inválido, dependencia no disponible, configuración ausente o conflicto de negocio. Una cola de cuarentena permite revisar casos que no deben reintentarse automáticamente. El panel operativo muestra retraso, último evento correcto, volumen pendiente y causa del fallo, con alertas ligadas a impacto. Además, las reconciliaciones comparan periódicamente pedidos, cantidades y totales entre plataformas. La integración no está sana solo porque el conector indique “activo”; está sana cuando el negocio puede demostrar que los conjuntos relevantes coinciden o conocer exactamente por qué no lo hacen.
El despliegue debe ensayarse con casos incómodos: pedido duplicado, cancelación parcial, cambio de dirección, devolución, producto sin referencia, combinación agotada y caída temporal de una API. Se valida qué ve el cliente y qué recibe el equipo en cada escenario. En producción se comienza, si es posible, con un alcance limitado y una observación reforzada. Existe un procedimiento para pausar consumo sin perder eventos y otro para reprocesar después de corregir el origen. Las credenciales se restringen a las operaciones necesarias y se rotan. Documentar estas decisiones reduce dependencia de una sola persona. El objetivo no es mover datos deprisa, sino mantener una historia comercial e inventario coherentes incluso cuando alguno de los componentes falla.
Comprobaciones antes de cerrar
- 01Maestro explícito
Cada entidad y campo crítico tiene origen y dirección definidos.
- 02Idempotencia
Repetir mensajes no duplica pedidos, clientes ni movimientos.
- 03Fallo ensayado
Caída, latencia y datos inválidos producen estados recuperables.
- 04Reconciliación diaria
Diferencias se detectan y reparan con operaciones auditables.
Revisa contratos y mapeos en cada actualización. Una nueva personalización puede cambiar el significado de un campo aunque la API siga respondiendo.
Control editorial
Metodología y fuentes
La integración se diseña a partir de modelos de datos, idempotencia y tratamiento de errores de ambas APIs.
- Odoo 19 Documentation ↗
Documentación oficial de módulos, administración e integraciones de Odoo.
- PrestaShop Webservice ↗
Documentación oficial de la API Webservice de PrestaShop.
