Conecta tu Odoo a Claude con una API Key y crea tus propias vistas sin escribir Python

Un hilo en el grupo Odoo México de Facebook nos recordó algo incómodo: la comunidad de código abierto ya había resuelto este problema antes de que llegara el consultor a cotizar miles de dólares. Aquí está el cómo, para cualquier versión y cualquier edición de Odoo, y aquí están los contras que casi nadie te cuenta.

La chispa: una pregunta legítima y ocho respuestas caras

En el grupo Odoo México de Facebook, alguien preguntó lo que muchos hemos pensado alguna vez:

"¿Quién tiene un módulo para consultar reportes con IA para Odoo Community?"

Las respuestas eran previsibles: "con gusto te lo puedo desarrollar", "tenemos uno ya en funcionamiento", "hola con gusto te podemos ayudar", "se te realiza a buen costo". Una comunidad haciendo lo que hace mejor: cotizar.

Y en medio del hilo, la respuesta que rara vez se dice en voz alta:

"¿Por qué no solo generas la API Key y se la pasas a cualquier agente de IA para que te genere conexión con el MCP y te haga vistas personalizadas?"

Cualquier versión de Odoo. Cualquier edición. Sin instalar módulos de terceros. Sin cotizar nada. Sin escribir una sola línea de Python.

Este artículo es la versión larga y honesta de esa respuesta. Con el paso a paso, sí, pero también con la letra chica que la mayoría de los posts se saltan: la deuda técnica que introduces, la dependencia que creas, los cobros de Odoo que puedes gatillar sin darte cuenta, y por qué esto no reemplaza a un buen consultor, lo empodera.

Lo que Odoo ya trae de fábrica y casi nadie usa

Antes del tutorial: Odoo lleva años enviando, dentro del menú Técnico, una caja de herramientas que la mayoría de los usuarios no sabe que existe:

• Vistas personalizadas: lista, kanban, formulario, pivote, gráfico, calendario.
• Campos: añadir campos computados o relacionados a modelos existentes.
• Modelos: inspeccionar la estructura real de los datos.
• Elementos de menú: colgar tus vistas de un lugar visible.
• Filtros de usuario: guardar el filtro que usas todos los lunes.

Nada de esto necesita Python. Se compone con XML y QWeb, que es HTML con superpoderes. Si le pides a un modelo de lenguaje que te escriba esa vista, la escribe sin problema, porque de eso está lleno el corpus público de Odoo desde hace más de una década.

El "módulo de IA para reportes" que te van a cotizar por miles de dólares, en la mayoría de los casos, es exactamente esto envuelto en un manifest.

Fuente del diagrama (Mermaid)

mindmap
  root(("Menu Tecnico
de Odoo"))
    Interfaz de usuario
      Vistas personalizadas
      Elementos de menu
      Filtros de usuario
    Estructura de datos
      Modelos
      Campos
      Seleccion de campos
    Todo sin Python
      XML y QWeb

Fuente del diagrama (Mermaid)

flowchart LR
    U(["Usuario"]) -->|"1. Genera"| K["API Key en Odoo\nPerfil, Preferencias, Seguridad"]
    K -->|"2. Configura"| M["Agente de IA + servidor MCP"]
    M -->|"3. Lee esquema real"| S[("Modelos y campos\nfields_get / list_models")]
    S --> M
    M -->|"4. Escribe"| V["Vista personalizada\nXML / QWeb, sin Python"]
    V -->|"5. Verifica en navegador"| U

Tutorial: cómo conectarlo tú mismo, paso a paso

Fuente del diagrama (Mermaid)

flowchart LR
    P1["Paso 1\nGenera la API Key\nPerfil, Preferencias,\nSeguridad"] --> P2["Paso 2\nConecta el MCP\nde Odoo al agente"] --> P3["Paso 3\nDescribe la vista\nen espanol"] --> P4["Paso 4\nVerifica en\nel navegador"] --> P5["Paso 5\nGuarda memoria\ndel cambio"]
    style P4 fill:#E14228,stroke:#E14228,color:#FFFFFF

Paso 1: genera tu API Key en Odoo

Dentro de Odoo, con tu usuario: Perfil, Preferencias, pestaña Cuenta o Seguridad, Nueva API Key.

Ponle un nombre descriptivo (por ejemplo, claude-mcp-septiembre2026). Odoo te muestra la key una sola vez, cópiala de inmediato a un gestor de contraseñas. Si la pierdes, generas otra; no es recuperable.

Funciona en Community, Enterprise, Odoo Online y Odoo.sh. Funciona en v14, v15, v16, v17, v18 y v19. Es un mecanismo nativo, no un truco.

Paso 2: da de alta un MCP de Odoo en tu agente de IA

MCP significa Model Context Protocol, el estándar abierto que conecta agentes de IA con sistemas reales.

Elige el conector que tu stack soporte:

• Un servidor MCP de Odoo que corra en Docker y exponga las operaciones típicas (odoo_search_read, odoo_fields_get, odoo_list_models, odoo_create, odoo_write, odoo_execute). Es el enfoque que usamos internamente en Transgenia.
• Wrappers XML-RPC más ligeros para Claude Desktop, Cursor o VS Code.

Tu MCP necesita cuatro datos:

ODOO_URL=https://tu-instancia.odoo.com
ODOO_DB=nombre-de-tu-base
ODOO_USER=usuario-que-genero-la-key
ODOO_API_KEY=la-key-del-paso-1

Paso 3: descríbele a la IA lo que quieres, en español

Ejemplo real de instrucción que funciona:

"En el módulo Ventas, crea una vista de lista de cotizaciones (sale.order en estado enviado) con más de 7 días desde su creación, agrupadas por vendedor y por etiqueta de sector. Columnas: número, cliente, vendedor, importe total, días desde el envío. Cuélgala del menú Ventas, Reportes, Cotizaciones estancadas."

El agente hará tres cosas:

1. Consultar el esquema real (fields_get sobre sale.order) para no inventar campos.
2. Generar el XML de la vista, la acción de ventana y el elemento de menú.
3. Escribirlo directo por la API, o entregártelo para que lo pegues manualmente en Vistas personalizadas.

Paso 4: verifica antes de creer

Este es el paso que la mitad de los tutoriales omite. Antes de dar por buena la vista:

• Abre el menú y navega la vista en el navegador.
• Confirma que las columnas muestran datos reales (no valores vacíos ni errores).
• Aplica los filtros y las agrupaciones; que agrupen por lo que pediste y no por otra cosa parecida.

Si algo se ve raro, pídele al agente que lea de vuelta la vista que acaba de crear. Sí, la IA se equivoca. La diferencia es que ahora tú la corriges en dos mensajes, en vez de esperar dos semanas de un ticket de consultoría.

Paso 5: guarda memoria del cambio

Anota en algún lado (un documento, una nota interna) qué vista creaste, con qué instrucción, en qué fecha y qué usuario tenía la API Key. Este paso parece opcional. No lo es. La sección de contras te explica por qué.

La reflexión incómoda: el rentismo del consultor tradicional

Aquí es donde el artículo se pone denso, así que lo digo directo.

Un consultor senior con diez años en Odoo puede leer esto y sentir dos cosas al mismo tiempo:

1. "Me están tumbando el negocio." Facturas de cinco, ocho, quince mil dólares por un módulo de reportes que un usuario avanzado puede clonar en una tarde con un agente de IA y una API Key.
2. "Al fin puedo dejar de vender esto." Porque en el fondo, cobrar decenas de horas por una vista personalizada nunca fue el trabajo que uno se imaginó cuando estudió arquitectura de sistemas.

La comunidad de código abierto lleva años recomendando este camino. Las vistas personalizadas, Studio en Enterprise, la API JSON-RPC, el desarrollo en XML sin Python: todo esto está en la documentación oficial de Odoo desde hace más de una década. Lo que cambió en 2024 y 2025 fue que apareció una herramienta, los agentes de IA con MCP, que baja el costo de escribir ese XML de "un consultor con años de experiencia" a "un usuario avanzado con paciencia y buenas preguntas".

Este cambio no elimina la consultoría seria. La consultoría seria es arquitectura de datos, decisiones de proceso, seguridad, control de accesos, migraciones, integración con el SAT y el CFDI, disciplina fiscal y gobierno del ERP. Todo eso sigue requiriendo un ser humano con criterio.

Lo que sí elimina, y en buena hora, es la consultoría rentista: la que factura horas por lo que hoy es un click, una instrucción y un menú nativo. Los consultores, desarrolladores y technical project managers que se aferran a ese modelo van a competir contra usuarios finales cada vez más autónomos. Los que evolucionen hacia gobernanza, arquitectura y criterio van a estar mejor pagados que nunca, porque el mercado por fin va a distinguir la diferencia.

Fuente del diagrama (Mermaid)

flowchart TD
    C["El trabajo del consultor de Odoo"] --> R{"Que tipo de trabajo?"}
    R -->|"Rentista"| X["Cobrar horas por una vista\no un reporte ad-hoc"]
    R -->|"Serio"| K["Arquitectura, seguridad,\nmigracion, gobierno del ERP"]
    X --> XD["Lo absorbe el usuario\navanzado con IA"]
    K --> KP["Sigue requiriendo\ncriterio humano"]
    style XD fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style KP fill:#14532d,stroke:#3ba55d,color:#FFFFFF

Pros, en corto

• Velocidad: minutos, no semanas.
• Sin proveedor cautivo: no dependes de un módulo cerrado que quizá no sobreviva al próximo upgrade.
• Iteración conversacional: pides, ves, ajustas, sin la ceremonia de los tickets.
• Todo dentro del core: no metes código Python de terceros a tu instancia.
• Portabilidad: la vista vive en ir.ui.view como cualquier otra vista nativa.

Contras: la letra chica que casi nadie te cuenta

Esta sección es la razón real por la que este artículo existe. Los pros ya te los venden en todos lados; los contras, rara vez.

Fuente del diagrama (Mermaid)

mindmap
  root(("API Key + IA
en Odoo"))
    Pros
      Velocidad
      Sin proveedor cautivo
      Iteracion conversacional
      Dentro del core
    Contras
      Deuda tecnica
      Dependencia de la maquina
      LoC facturables
      Control de accesos

Fuente del diagrama (Mermaid)

flowchart TD
    A["Le pides un cambio a la IA"] --> B{"Requiere Python?"}
    B -->|"No: XML / QWeb / vista"| C["Seguro\nNo cuenta como LoC"]
    B -->|"Studio con safe_eval simple"| C
    B -->|"Si: def / class / import\nen server action"| D["Odoo lo contabiliza\ncomo lineas de codigo"]
    D --> E{"Estas en Odoo Online\no Odoo.sh?"}
    E -->|"Si"| F["Puede ser facturable\npor Odoo SA"]
    E -->|"No: Community self-hosted"| G["No se factura,\npero es deuda tecnica"]

1. Deuda técnica invisible

Una vista creada por conversación con IA no vive en un repositorio git. No hay diff, no hay revisión por pares, no hay historial de "quién cambió qué y por qué" más allá del write_uid y el write_date del registro.

En la práctica esto significa que:

• Al migrar de versión, esas personalizaciones pueden romperse en silencio y nadie sabe dónde buscar.
• Cuando la instancia crezca a decenas o cientos de vistas creadas así, no hay forma sana de auditarlas.
• Los tests automatizados no las cubren, porque no existen como código en tu integración continua.

Es el equivalente a construir sobre una casa sin planos: funciona, hasta que hay que remodelar.

Fuente del diagrama (Mermaid)

flowchart LR
    subgraph IA["Vista creada por conversacion"]
      I1["Sin repositorio git"] --> I2["Sin diff ni revision"] --> I3["Migracion:\nse rompe en silencio"]
    end
    subgraph GIT["Modulo bajo control de versiones"]
      G1["Vive en git"] --> G2["Diff, PR, pruebas"] --> G3["Migracion:\nreproducible"]
    end
    style I3 fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style G3 fill:#14532d,stroke:#3ba55d,color:#FFFFFF

2. Dependencia de la computadora del dueño

Este es el punto que más se subestima. La API Key vive en tu máquina: en el archivo de configuración de tu MCP local, en el config de Claude Desktop, en el mcp.json de tu editor. En una laptop concreta, física, que puede morir.

Consecuencias:

• Si el agente de IA que hace las modificaciones corre en la laptop del dueño de la instancia, no hay alta disponibilidad, no hay respaldo del contexto de la conversación, y si esa máquina muere, se pierde el "cómo se hizo".
• No es un servicio con acuerdo de nivel de servicio. Es una configuración local a la máquina de una persona.
• Si esa persona se va de la empresa con su laptop, la organización queda ciega respecto a las personalizaciones que se hicieron.

Es distinto a un módulo de terceros, que al menos vive en addons con su manifest, o a un cambio hecho por un consultor externo, que al menos deja un ticket cerrado y una factura como huella.

3. Responsabilidad hacia Odoo: las famosas líneas de código

Este es el punto que apareció en el hilo original y merece un párrafo aparte.

En Odoo Online (SaaS) y Odoo.sh, las modificaciones se contabilizan y pueden ser facturables como personalización, según el modelo comercial de Odoo SA. La regla operativa práctica:

• Vistas personalizadas (XML puro, sin una server action con Python detrás): seguras, no cuentan como líneas de código.
• Studio con lógica visual simple (filtros, cálculos con safe_eval): en general, seguras.
• Server actions con Python (def, class, import, funciones complejas): estas sí las contabiliza Odoo como líneas de código y son susceptibles de facturación.
• Automatizaciones con código: igual.

Si le pides a la IA que "resuelva" un cálculo complejo escribiéndote una server action de treinta líneas de Python, felicidades: acabas de generar deuda técnica y además un costo variable con Odoo SA.

Un consejo que sale del propio hilo: si Odoo intenta cobrarte líneas de código por personalizaciones, pídeles el reporte de auditoría sin líneas HTML, porque el HTML, el XML y el QWeb no deberían contar como código Python, y ese reporte te deja ver la cuenta cruda.

4. Control de accesos: el problema del radio de daño

La API Key de Odoo hereda todos los permisos del usuario que la generó. Ese es su diseño. No hay permisos granulares por operación en el Odoo estándar.

Consecuencias:

• Si la API Key la generó el administrador, y esa key se la das a un agente de IA que corre en un servidor MCP conectado a internet, el radio de daño en caso de fuga es todo el ERP: facturas, clientes, empleados, contabilidad, todo.
• Un agente con acceso de administrador puede, por accidente o por una inyección de instrucciones, ejecutar un borrado sobre modelos críticos.

Buena práctica no negociable:

1. Crea un usuario dedicado, por ejemplo [email protected].
2. Asígnale grupos mínimos: solo lectura donde sea posible, escritura solo en los modelos que necesita.
3. Genera la API Key desde ese usuario.
4. Nunca uses la API Key de un usuario administrador.
5. Rota la key cada 60 o 90 días.
6. Registra qué agente y qué máquina la está usando.

Fuente del diagrama (Mermaid)

flowchart TD
    subgraph MAL["Riesgoso"]
      A1["API Key del administrador"] --> A2["El agente hereda\nTODOS los permisos"] --> A3["Radio de dano:\ntodo el ERP"]
    end
    subgraph BIEN["Recomendado"]
      B1["Usuario dedicado ai-bot"] --> B2["Permisos minimos,\nsolo lo necesario"] --> B3["Radio de dano:\nacotado"]
    end
    style A3 fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style B3 fill:#14532d,stroke:#3ba55d,color:#FFFFFF

5. Reproducibilidad y entornos

No hay ruta de staging a producción para una vista creada por conversación. Si tu instancia se corrompe y restauras un respaldo de hace dos semanas, todas las vistas creadas después de esa fecha desaparecen, a menos que las hayas exportado a mano o documentado su instrucción de origen para regenerarlas.

En un módulo tradicional bajo git, un checkout reproduce el estado. Aquí no.

6. Continuidad del conocimiento

Si el usuario que conversó con el agente para crear la vista se va de la empresa, quién sabe qué instrucciones usó, qué campos calculados existen, qué depende de qué. Sin documentación intencional, cada personalización creada así es una pequeña caja negra.

7. Alucinación de esquema

Un agente sin acceso al esquema real puede inventar campos que no existen. La vista compila mal, o compila bien pero muestra vacío para todo. Buena práctica: pídele al agente que valide siempre contra el modelo real antes de escribir. Los conectores maduros exponen esa capacidad; úsala.

Cuándo sí y cuándo no usar este patrón

Fuente del diagrama (Mermaid)

flowchart TD
    Q{"Que vas a construir?"} -->|"Reporte ad-hoc,\npiloto, prototipo"| SI["Adelante tu mismo"]
    Q -->|"Proceso critico, CFDI,\nseguridad, go-live formal"| NO["Con acompanamiento\nprofesional"]
    SI --> SI2["Superusuario\ncon criterio"]
    NO --> NO2["Consultor + gobierno\ndel ERP"]
    style SI fill:#14532d,stroke:#3ba55d,color:#FFFFFF
    style NO fill:#7a2018,stroke:#E14228,color:#FFFFFF

Cuándo sí:

• Pilotos rápidos, prototipos, prueba de valor antes de comprar consultoría.
• Reportes ad-hoc de superusuarios (analistas, controllers, jefes de área).
• Instancias Community self-hosted donde no aplican los cobros de Odoo SA.
• Exploración y capacitación interna del equipo.

Cuándo no, sin acompañamiento profesional:

• Procesos críticos con varios usuarios en producción.
• Cambios que tocan seguridad, CFDI, contabilidad u obligaciones fiscales.
• Cualquier cambio que requiera un go-live formal, capacitación de usuarios y un plan de reversa.
• Instancias Odoo Online sin haber leído los términos de personalización.
• Cualquier situación en la que el usuario avanzado no entienda bien lo que la IA acaba de escribir.

El papel real del consultor, del desarrollador y del technical PM

Cierro con esto, que es la razón por la que Transgenia publica este artículo en vez de guardárselo.

Esta técnica no sustituye al consultor serio. Lo empodera para no cobrar consultoría por lo que hoy es un click con supervisión.

Y libera al technical project manager y al desarrollador senior para el trabajo que sí requiere criterio y experiencia:

• Arquitectura de datos y de procesos.
• Gobierno del ERP: quién puede hacer qué.
• Migraciones entre versiones sin perder personalizaciones.
• Integraciones con el SAT, bancos, marketplaces, catálogos de producto.
• Auditoría fiscal y de CFDI.
• Diseño de la disciplina operativa: cómo se documentan los cambios, cómo se prueban, cómo se despliegan, cómo se revierten.

En Transgenia usamos exactamente este patrón: un conector MCP hacia Odoo, un usuario dedicado con permisos mínimos y un consultor humano gobernando lo que el agente escribe. No para ahorrarnos horas de facturación, sino para liberarlas hacia trabajo que sí compone valor a largo plazo.

Si vas a probarlo tú mismo, bienvenido al club: ya sabes cómo empezar. Y si te pasa que la vista rompe la producción, que Odoo empieza a cobrarte líneas de código o que la API Key se filtró, ahí sí conviene una llamada. Ese, precisamente, es el trabajo que no desaparece.

Preguntas frecuentes

Sobre el autor y Transgenia

Efraín Carreón Ortiz es Director General de Centrum Transgenia, una boutique tecnológica mexicana. Está acreditado con la insignia oficial Claude Code (Claude Partner Badge) emitida por Anthropic, verificable en Credly.

Transgenia es OpenAI Select Partner dentro del OpenAI Partner Network y partner registrado en el Claude Partner Network de Anthropic. Operamos doce agentes de IA gobernados en producción propia y acompañamos implementaciones verificables en los sectores salud y B2B.

Hablemos: LinkedIn, agenda de 15 minutos o la página de contacto.

Sigue leyendo

• Cómo Transgenia opera con agentes de IA gobernados: el modelo de gobierno (draft-first, VoBo humano, MCP) detrás de este patrón.
• Implementar Claude en tu empresa: guía por fases: el método completo de adopción, de un partner registrado de Anthropic.
• Bajamos a cero nuestra factura de ERP: de Odoo Enterprise a Community: por qué las líneas de código y la edición importan.
• Nuestras soluciones de IA y Transgenia como OpenAI Select Partner.