Merece la pena quitar el middleware cuando esa capa guarda un estado que Odoo debería tener: el stock que se publica, el estado real de cada pedido, el tracking que vuelve al canal. No merece la pena cuando solo transporta: recibe un fichero y lo deja en otro sitio sin decidir nada. Esa es la regla entera. Lo que sigue: cuándo la respuesta honesta es «no muevas» y cómo se hace el cambio sin dejar de servir pedidos, contado desde nuestra propia migración a conectores que hablan directamente con la API del tercero en producción.
Idea clave: el middleware no te cuesta la cuota. Te cuesta que la verdad de tu operación viva en dos sitios. Cada estado que existe en la capa intermedia y también en Odoo es una reconciliación que alguien hace a mano o que nadie hace.
Qué te cuesta el middleware en trabajo diario, no en dinero
El argumento de quitar una capa ya lo hicimos con la factura electrónica en SERES desde Odoo, y la comparativa de fondo está en Odoo 19 frente a conectores con middleware. Con marketplaces y transportistas es lo mismo multiplicado por los pedidos del día: cuatro tareas que nadie presupuesta.
| Tarea | Con middleware | Con conexión nativa |
|---|---|---|
| Maestro de productos | Dos: Odoo y el mapeo del middleware | Uno. El mapeo al canal es un campo del producto |
| Estado del pedido | Tres verdades: marketplace, middleware y Odoo | Dos: el canal y Odoo, con el estado remoto junto al pedido |
| Trazabilidad de un envío | Pedido en Odoo, tracking en el middleware, confirmación en el marketplace | Pedido, albarán, tracking y confirmación en la misma ficha |
| Quién mira el log | El panel del proveedor, con su usuario y su retención | Un modelo de Odoo con petición y respuesta, filtrable y con purga |
La fila del log merece una advertencia: «lo tenemos en Odoo» no significa que se escriba. En la auditoría de nuestro conector de Mirakl, la función que registraba cada llamada preguntaba if not log_model, y el ayudante devolvía un recordset vacío cuando todo iba bien; en Odoo un recordset vacío es falso, así que el registro fue un no-op desde el primer día. La prueba estaba en producción: la secuencia de esa tabla seguía en NULL tras meses de crones. Hoy la comprobación es if log_model is False.
Cuándo no hay que mover: los tres casos claros
- Varios ERP. Si Odoo lleva una sociedad y otro sistema lleva otra, y ambas venden en los mismos canales, el middleware es el único sitio donde el stock publicado es la suma de los dos.
- Orquestación entre terceros. Si el flujo es marketplace → operador logístico externo → transportista y Odoo solo se entera al final, la capa dirige sistemas que no son tuyos.
- Nadie que mantenga Odoo. Un conector nativo es código dentro de tu ERP. Si nadie, interno o partner de Odoo, va a hacer ese trabajo, el middleware con su cuota es la opción barata.
El plan de migración sin parar la operación
Cuatro pasos y un principio: la conexión nativa entra leyendo y no escribe hacia fuera hasta que lleva días leyendo lo mismo que el middleware. Lo aplicamos en junio de 2026 al sustituir, en nuestra propia producción en Odoo.sh, un módulo antiguo de Amazon por el conector que habla con SP-API directamente.
1. Inventario de flujos, con dirección
Una fila por flujo: pedidos que entran, stock y precios que salen, tracking que sale, cancelaciones y devoluciones que entran, facturas que suben. Para cada una, dirección, frecuencia y disparador (cron, webhook o persona). Un marketplace de Mirakl da entre ocho y doce filas; un transportista, tres o cuatro; una plataforma de firma, dos.
2. Orden: lectura antes que escritura
El conector nativo se instala con todas las escrituras hacia el tercero apagadas: en el nuestro, un interruptor global más un indicador por cuenta para cada acción que sale. Solo lee pedidos, estados e inventario; el middleware sigue escribiendo y nadie deja de servir. Aquí salió el primer fallo del corte: el importador nuevo comprobaba si un pedido existía mirando su propia tabla, recién creada y vacía, y no los pedidos de venta que el sistema anterior ya había creado. Resultado: diecisiete pedidos de venta duplicados y confirmados, cada uno reservando stock otra vez. El arreglo fue buscar la referencia del marketplace en sale.order antes de crear nada. La regla: se deduplica contra el destino, nunca contra la tabla intermedia del propio conector.
3. Periodo en paralelo con comparación diaria
Una o dos semanas con los dos sistemas leyendo el mismo canal y, cada mañana, una lista corta: pedidos que uno importó y el otro no, estados que no coinciden, SKU sin casar. Cero dos días seguidos, y entonces la primera escritura.
4. Corte por canal, y escrituras solo hacia delante
Se corta un canal, no todos. Y al encender las escrituras, solo las que dispara una transición: confirmar el envío al validar un albarán es seguro, porque ocurre una vez por pedido que de verdad sale. Lo que no es seguro es un cron que recorra registros existentes y los reenvíe. En nuestro corte quedaban 534 albaranes históricos hechos y marcados «pendiente de sincronizar» por el módulo antiguo; el cron de reintentos los encontró y mandó 28 confirmaciones de envío a Amazon en cuatro minutos, antes de que lo apagáramos. La lección: antes de encender un cron de barrido, reconcilia el histórico que queda en el estado que ese cron busca.
Los datos históricos: qué se migra y qué se deja en solo lectura
Se migra lo que todavía puede cambiar: pedidos abiertos, el mapeo SKU ↔ referencia del canal, envíos cuyo tracking aún no ha vuelto al marketplace y devoluciones en curso. No se migra el histórico de llamadas ni los pedidos cerrados: se pide acceso de solo lectura a su panel durante el plazo de reclamaciones. En nuestro corte los datos de negocio no se tocaron: 1.838 pedidos de venta y 13.236 productos siguieron donde estaban.
Cómo se comprueba que la conexión nativa funciona antes del corte
Con una build real de Odoo y el sandbox del tercero, no con mocks. Lo contamos con números en los tests estaban en verde y el conector no funcionaba: un conector con 236 de 236 tests en verde en Odoo 19, 18 y 17 tenía 32 fallos reales debajo, y otro con 163 de 163 nunca había escrito una línea de log. Las tres pruebas que importan:
- La ventana de sincronización pide lo cambiado, no lo creado. Lo cometimos dos veces: el conector de Mirakl enviaba
start_date(creación) en vez destart_update_date, y el de AliExpress filtraba por fecha de creación desde la última pasada. En ambos, un pedido creado por la mañana y enviado por la tarde no volvía a entrar en la ventana y su estado en Odoo se quedaba congelado. - El log tiene filas. Tras la primera importación, cuenta los registros del modelo de log. Cero significa que no se escribe, no que no haya errores.
- La traza está en la ficha. Desde un pedido importado tienes que llegar al pedido de venta, al albarán y al tracking sin salir de Odoo.
Qué queda después: quién mantiene el conector en la siguiente versión de Odoo
Esta es la parte que el middleware te ahorraba y ahora es tuya. Cada versión de Odoo cambia algo que un conector toca: en 19, read_group está marcado como obsoleto en el propio ORM; en 18 las vistas de lista pasaron de <tree> a <list>; en 17 un ir.cron sin numbercall corre una vez y se apaga solo. Ninguna de las tres da error al instalar. Nuestros conectores se publican para 19, 18 y 17 a la vez y se prueban en builds reales de cada serie. Antes de mover, decide quién hace ese trabajo: tu equipo, un partner de Odoo, o el autor del conector si lo publica para varias versiones y lo migra en cuanto sale la nueva.
Si el conector es para tu propio software, en conector Odoo para tu software explicamos cómo lo hacemos con partners tecnológicos; en el catálogo están los que ya hablan con Amazon, Mirakl, ManoMano, AliExpress y los transportistas. Con varios canales, el orden de corte depende de qué canal publica el stock: lo tratamos en vender en varios marketplaces desde un solo Odoo y stock en tiempo real para marketplaces.
Checklist de decisión
- ¿El middleware guarda stock, estado de pedido o tracking que Odoo no tiene? Si solo transporta ficheros, no muevas.
- ¿Un solo ERP, o varios vendiendo en los mismos canales? ¿Odoo se entera del pedido al principio del flujo o al final?
- ¿Quién pasa el conector a la siguiente versión de Odoo, y cuándo?
- ¿Sabes cuántos registros históricos quedan en el estado que un cron de reintentos busca?
Si quieres que alguien mire tu caso con estos criterios, en servicios y soluciones está cómo trabajamos.
Preguntas frecuentes
¿Cuánto tiempo hay que tener los dos sistemas en paralelo?
Hasta que la comparación diaria dé cero diferencias dos días seguidos, y nunca menos de una semana.
¿Se puede mover un canal y dejar los demás en el middleware?
Sí, y es lo recomendable. Solo hay que decidir quién publica el stock a ese canal a partir del corte, y que sea uno solo.
¿Vale lo mismo para EDI y firma electrónica que para marketplaces?
La regla sí: si la capa guarda el estado del documento (aceptado, rechazado, firmado), moverla merece la pena. Hay dos o tres flujos en vez de diez, y el paralelo se hace enviando el mismo documento por los dos caminos al entorno de pruebas del tercero.
Enlaces útiles dentro de FlexigoTech
Lo que hacemos sobre esto
¿Pagas un middleware y no sabes si te sobra?
Cuéntanos qué canales tienes, qué versión de Odoo y quién la mantiene. Te decimos si mover merece la pena, en qué orden, y qué debe seguir en el middleware. Escribe a comercial@flexigobe.com o llama al +34 616 809 504.