Sincronización Total: Conectando Odoo con PrestaShop en tiempo real
Deja de copiar pedidos a mano. Te enseñamos la arquitectura técnica para unificar tu E-Commerce con tu ERP y automatizar la logística.
Autor y revisor: Jon González
El Puente Digital
Tienes una tienda en PrestaShop (o WooCommerce) que vende bien. Tienes un ERP Odoo para llevar la facturación y el almacén.
Pero entre medias… hay un humano. Un humano que cada mañana descarga los pedidos de la web y los teclea en Odoo. Un humano que actualiza el stock en la web cuando entra mercancía en el almacén.
Ese humano comete errores. Se pone enfermo. Se va de vacaciones. Y cuando llega el Black Friday y entran 500 pedidos, ese humano colapsa. Y los pedidos salen tarde.
La Sincronización Bidireccional es conectar el cerebro (ERP) con el escaparate (Web) para que hablen el mismo idioma en tiempo real.
Arquitectura de la Conexión
No usamos “conectores mágicos” de 50€. Diseñamos integraciones robustas mediante API.
Flujo 1: Catálogo (Odoo → Web)
Odoo es el maestro. Creas el producto en Odoo, le pones precio, fotos y descripción. Al guardar, nuestro conector envía esa info a PrestaShop. Si cambias el precio en Odoo, cambia en la web al instante. Ventaja: Tu equipo administrativo no tiene que entrar al panel de la web para nada. Trabajan solo en su ERP.
Flujo 2: Stock (Odoo ↔ Web)
Es lo más crítico.
- Venta en tienda física (TPV Odoo): Se resta 1 unidad. Odoo avisa a la Web: “Quedan 4”.
- Venta en Web: Se resta 1 unidad. La Web avisa a Odoo: “Reserva 1”. Odoo actualiza su stock disponible.
- Entrada de mercancía de proveedor: El almacenero pistola el código de barras en Odoo. El stock sube. La Web muestra “En stock” automáticamente.
Adiós a las roturas de stock.
Flujo 3: Pedidos (Web → Odoo)
El cliente paga en la web. Al instante, el pedido aparece en Odoo como “Presupuesto Confirmado”.
- Se crea la ficha del cliente en Odoo (si es nuevo).
- Se asigna el transportista correcto.
- Se genera el albarán de salida en el almacén.
El almacenero ve en su tablet: “Nuevo pedido para preparar”. Lo mete en la caja, cierra, y Odoo envía el número de tracking a la web, que a su vez envía el email de “Enviado” al cliente.
Todo esto sin que nadie en administración haya tocado un papel.
Gestión de Conflictos
¿Qué pasa si un cliente compra el último ítem en la web justo cuando alguien lo compra en la tienda física? Nuestros conectores gestionan bloqueos de registro y colas de prioridad. Siempre hay una “Single Source of Truth” (Fuente Única de Verdad).
El valor de los datos unificados
Al tener todo conectado, puedes ver informes reales:
- ¿Qué productos se ven mucho en la web pero no se compran?
- ¿Qué clientes compran online Y offline (Omnicanalidad)?
- ¿Cuál es el margen real de cada venta web (descontando costes logísticos reales)?
Implementación
Esto no es instalar un plugin. Es un proyecto de ingeniería. Requiere mapear impuestos, mapear estados de pedido, mapear categorías. Pero una vez hecho, tu capacidad operativa es infinita. Puedes procesar 10 pedidos diarios o 10.000. El sistema no se cansa.
Si tu objetivo es escalar, necesitas este puente.
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 sincronización total: conectando odoo con prestashop en tiempo real 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.
