Conectar una aplicación a Odoo sin crear una segunda verdad

Digamos que ya decidiste que un proceso necesita su propia pantalla, fuera del ERP. Un portal para que el piso reporte producción, una estación de empaque, una tienda privada para distribuidores.

Ahora viene la parte donde el proyecto se echa a perder, y casi siempre se echa a perder igual: la aplicación empieza a guardar cosas.

Primero es el catálogo, «para que cargue rápido». Luego los precios, «porque son los mismos». Luego los pedidos, «nada más mientras se confirman». Seis meses después hay dos sistemas, alguien los concilia los viernes, y cuando no cuadran nadie sabe cuál tiene razón.

Estas son las seis reglas que usamos para que eso no pase. Ninguna es complicada; lo difícil es sostenerlas cuando aparece la prisa.

1. La aplicación no tiene base de datos. Tiene caché

La distinción parece semántica y no lo es. Es la regla que sostiene a las otras cinco.

Una base de datos guarda cosas que sólo ella sabe. Una caché guarda copias de cosas que sabe alguien más, y su propiedad definitoria es que se puede borrar entera sin perder nada.

Ésa es la prueba, y es binaria: si borras todo lo que la aplicación guardó y vuelves a arrancarla, ¿pierdes información? Si la respuesta es sí, ya tienes dos sistemas aunque no quisieras.

En la práctica: cachea catálogos, nombres, categorías, listas que cambian poco. Ponles un vencimiento. Y sé mucho más cuidadoso con precios y existencias, que son los dos datos donde una copia vieja no es lentitud — es un compromiso que no puedes cumplir.

2. La sesión de la aplicación no es la sesión del ERP

Aquí hay una decisión real, con dos caminos legítimos, y conviene tomarla a propósito en lugar de heredarla.

Camino A: cada persona entra con su usuario del ERP. La aplicación autentica contra Odoo y opera con las credenciales de quien está enfrente. Lo bueno es enorme: los permisos son los del ERP, y el rastro de quién hizo qué es el rastro real del sistema, no una nota. Lo caro también: hace falta un usuario por persona.

Camino B: la aplicación tiene sus propios accesos y opera con un usuario de integración. Un modelo de accesos creado con Studio guarda quién puede entrar, con qué contraseña y con qué nivel. No hay licencia por operador, que es exactamente el punto cuando son cuarenta.

El costo del camino B hay que decirlo completo: el rastro de auditoría deja de ser automático. Como todas las escrituras las hace el usuario de integración, el ERP dirá que fue él. Si quieres saber quién fue de verdad, la aplicación tiene que escribirlo — normalmente como una nota en el historial del documento. Y cada persona necesita su propia contraseña, porque una compartida convierte ese rastro en decoración.

Ninguno de los dos caminos es el correcto siempre. El A es para gente de tu empresa con responsabilidad; el B es para volumen, y para gente de fuera que nunca va a ser usuaria de tu ERP.

3. Escribe poco, y escribe de forma que repetirlo no duela

Una aplicación satélite bien hecha lee mucho y escribe muy poco. Cada escritura es una superficie donde algo puede duplicarse.

Y va a repetirse. La red se corta a la mitad de una petición, el operador presiona dos veces porque no vio respuesta, el proceso se reinicia justo después de escribir y antes de confirmar. No es un caso raro: es martes.

La defensa es que cada escritura lleve una referencia externa —un identificador que la aplicación genera y el ERP guarda— y que antes de escribir se busque si esa referencia ya existe. Si existe, no se vuelve a crear: se devuelve lo que ya se creó.

Es una línea de código y es la diferencia entre reintentar sin miedo y descubrir pedidos duplicados tres semanas después.

4. La caché necesita una puerta para invalidarse, y esa puerta necesita llave

Una caché con vencimiento de quince minutos significa que durante quince minutos puedes estar mostrando un precio viejo. Para catálogos está bien. Para el día que se actualiza la lista de precios, no.

La solución es dejar que el ERP avise: una acción automatizada en Odoo que, cuando cambian precios o productos, llame a la aplicación y le diga que tire esa parte de la caché. Se enteran las dos en segundos en lugar de en quince minutos.

Con una advertencia que hemos aprendido revisando este tipo de conectores: ese aviso es una puerta abierta y hay que ponerle llave. Un endpoint que vacía la caché sin autenticación es una invitación a que cualquiera te tire el rendimiento con un bucle. Un token compartido basta, y cuesta cinco minutos ponerlo el primer día — bastante más el día que hay que explicarlo.

5. No supongas la versión: pregúntasela al ERP

Odoo cambia nombres de campos entre versiones. Es normal y está documentado, pero si tu aplicación lleva el nombre cableado, funciona en la instancia donde la probaste y truena en la siguiente.

La alternativa es barata: al arrancar, pregúntale al ERP qué campos tiene ese modelo y quédate con el nombre que exista. Se hace una vez, se guarda en memoria y se acabó.

Ese pequeño gesto es lo que permite decir «funciona de la 16 a la 19» sin mantener cuatro versiones del código ni cruzar los dedos en cada instalación nueva. Y vale para más que los nombres: si tu aplicación necesita un campo opcional, pregunta si está antes de leerlo, en lugar de suponer que sí.

6. Lo que falta en el ERP se crea con Studio, no con un módulo

Ésta es la regla que decide en qué clientes vas a poder instalar lo que construiste, y por eso la dejamos al final aunque sea la más importante.

Casi cualquier aplicación satélite necesita algo que el ERP estándar no trae: un campo para la guía de la paquetería, un modelo con los accesos del portal, una marca en el producto. Hay dos formas de crearlo, y sólo una funciona en todas partes.

Si lo creas con un módulo, necesitas instalarlo. Y en Odoo Online el cliente no puede instalar módulos, así que acabas de dejar fuera a un segmento entero por una decisión de implementación, no de producto.

Si lo creas con Studio —campos y modelos personalizados— el cliente lo tiene igual en Odoo Online, en Odoo.sh y en servidor propio. La aplicación no se entera de la diferencia: son campos y los lee igual.

El criterio práctico: si tu aplicación vive fuera y sólo necesita campos y modelos, Studio alcanza. Lo que Studio no admite es subir JavaScript o CSS del backend, pero una aplicación satélite no los necesita — su interfaz es la suya, no la del ERP.

Lo que aceptas a cambio

Ninguna de estas reglas es gratis, y conviene tener la lista completa antes de empezar:

• Si el ERP no responde, la aplicación no opera. Es la contraparte directa de no tener una segunda base. No hay modo sin conexión, y fingir que lo hay es volver a inventar la segunda verdad por la puerta de atrás.
• La latencia es real. Cada pantalla son una o varias llamadas. Se compensa con caché donde se puede y midiendo dónde duele.
• Hay un servidor más que cuidar, con su costo anual y su monitoreo.

A cambio: nada que conciliar, ningún viernes revisando por qué dos sistemas difieren, y un solo lugar donde arreglar un dato cuando está mal.

Cómo lo resolvimos nosotros

Las seis reglas salieron de construir tres aplicaciones y equivocarnos en algunas antes de escribirlas.

El Portal Operativo usa el camino B de la regla 2 y escribe el nombre del operador en el historial de cada orden, justo por lo que dice esa regla. También detecta en tiempo de ejecución el nombre del campo de cantidad, que es la regla 5 en su forma más literal: entre Odoo 16 y 17 ese campo cambió de nombre.

El Portal B2B es el que más apoya en la caché y en su invalidación desde Odoo, porque un catálogo de mayoreo se navega mucho y se modifica poco.

OneButtonPrint tomó el camino A: cada operador entra con su propio usuario de Odoo, porque ahí lo que se registra es la validación de una transferencia y el rastro tiene que ser el del ERP.

Las tres se conectan y ninguna se instala, así que las tres funcionan igual en los tres entornos.

Si estás por conectar algo a tu Odoo y la conversación ya derivó hacia «y lo guardamos también de este lado», vale la pena que hablemos antes.