Guía · Personalización
Odoo Studio o desarrollo a medida en Odoo 20: cuándo conviene cada uno
- Autor
- Eduin Garnica, CTO
- Publicada
- Actualizada
- Versión
- Odoo 20
En corto
Odoo Studio personaliza Odoo sin programar —campos, vistas, modelos, automatizaciones, reportes y reglas de aprobación— y guarda los cambios en la base de datos; un módulo a medida es código que vive en archivos, normalmente en un repositorio, y llega a todo lo que permite el framework de Odoo. Studio viene con el plan Custom y funciona en Odoo Online, Odoo.sh y servidor propio; un módulo exige Odoo.sh o servidor propio. Al cambiar de versión, el servicio de actualización de Odoo convierte lo hecho con Studio mientras siga instalado y la suscripción activa, y un módulo lo adapta quien lo mantiene, salvo que tenga contrato de mantenimiento con Odoo.
Qué es cada uno
Entre lo que Odoo trae y lo que una empresa necesita hay tres caminos, y Studio y el desarrollo a medida son dos de ellos. El primero es lo estándar: activar una opción, configurar datos maestros o crear una regla de automatización. La propia documentación de Odoo pide agotarlo antes de construir. Su guía para actualizar bases personalizadas recomienda «challenge the developments as much as possible and find functional workarounds», porque quitar lo que un desarrollo duplica del estándar facilita la siguiente actualización y reduce la deuda técnica.
- Odoo Studio
- la herramienta de Odoo Enterprise para personalizar Odoo sin saber programar.
- Módulo a medida
- código que extiende el estándar de Odoo y que no se construyó con Studio, según la definición de la documentación de Odoo 20.0.
- Regla de automatización
- una acción que Odoo ejecuta sola ante un evento, como crear una actividad o actualizar un campo; viene en el módulo
base_automation, parte del código Community de Odoo 20, y Studio la edita desde su propia interfaz. - Servicio de actualización
- el servicio con que Odoo convierte una base a una versión más reciente, incluido sin costo en la suscripción Enterprise.
- Plan Custom
- el plan de Odoo Enterprise que incluye Studio, multiempresa, la API externa y los alojamientos Odoo.sh y servidor propio.
Qué resuelve Studio
Studio trabaja dentro de la interfaz de Odoo. La documentación de Odoo 20.0 lo define como «a toolbox used to customize Odoo without coding knowledge» y enumera lo que agrega o modifica en cualquier aplicación: campos, vistas, modelos, reglas de automatización, webhooks —avisos automáticos que un sistema envía a otro cuando ocurre algo—, reportes PDF, reglas de aprobación y reglas de seguridad. Con eso se resuelven pedidos frecuentes, como un campo que la operación necesita, una vista con otro orden, un reporte con el formato de la empresa o una aprobación antes de confirmar, sin ambiente de desarrollo ni despliegue.
Todo lo que se hace con Studio queda dentro de la base. Odoo lo agrupa en un módulo llamado studio_customization, que se puede exportar como ZIP e importar en otra base. La documentación pide que la base destino esté en la misma versión y tenga las mismas aplicaciones, porque Studio no declara como dependencias los módulos sobre los que trabaja.
Studio también admite código. Una regla de automatización puede ejecutar Python con la acción Execute Code, y ahí cambian dos cosas. La primera es el costo, que la documentación advierte en la misma página:
«For automation rules that require the execution of custom code, note that maintenance of custom code is not included in the Standard or Custom pricing plans and incurs additional fees.»
El contrato de suscripción lo dice con su propia definición: cuenta como módulo adicional tanto un directorio de código fuente como «a set of Python-based customizations created in a database (e.g. with Odoo Studio)». La segunda es el alcance. Ese código corre dentro de safe_eval, el evaluador restringido de Odoo, que en la rama 20.0 bloquea las instrucciones import (odoo/tools/safe_eval/evaluation.py). Lo que necesite importar una librería se escribe en un módulo.
Qué resuelve un módulo a medida
Un módulo trabaja sobre el framework completo de Odoo. Según la documentación para desarrolladores, puede contener objetos de negocio declarados como clases de Python, vistas, archivos de datos en XML o CSV —con reglas de seguridad, reportes o configuración—, controladores web que atienden solicitudes del navegador y archivos estáticos como imágenes, CSS o JavaScript. La lógica de negocio se escribe en Python, y la interfaz usa OWL, el framework de JavaScript propio de Odoo.
Su código vive en archivos, normalmente en un repositorio Git, que registra cada cambio con su autor y su fecha, y se instala en la base desde ahí. Eso tiene tres consecuencias:
- Exige un alojamiento que admita módulos. Es decir, Odoo.sh o servidor propio, porque Odoo Online no los acepta; la comparación completa está en la guía de alojamiento.
- Exige a alguien con Python que lo escriba y lo mantenga. El tutorial oficial pide nivel intermedio.
- Llega a piezas que la lista de Studio no nombra y se prueba como software. Controladores web, componentes de interfaz propios o lógica que importa librerías caben en un módulo, y Odoo trae para él pruebas unitarias de Python y de JavaScript, y recorridos (tours) que simulan a un usuario de punta a punta.
En qué plan está Studio
Studio es parte de Odoo Enterprise: el código Community de Odoo 20 no trae su módulo, web_studio, y la página de precios lo pone en el plan Custom, junto con multiempresa y la API externa. En el plan Standard, instalarlo cambia la suscripción:
«Installing Studio in an Odoo database on the Standard pricing plan automatically triggers an upsell to the Custom pricing plan.»
En los contratos anuales o multianuales, ese cambio llega como una orden con 30 días de plazo; en los mensuales, la suscripción pasa sola al plan Custom con la siguiente factura. Hay una excepción: el plan gratuito de una sola aplicación permite elegir Studio como esa aplicación.
El plan no inclina la balanza entre los dos caminos. Studio pide el plan Custom, y un módulo lo termina pidiendo también, porque Odoo.sh y el servidor propio sólo están en ese plan. Lo que se suma en los dos casos, en cuanto hay código, es su mantenimiento: la página de precios lo deja fuera de todos los planes, igual que el alojamiento en Odoo.sh.
Qué pasa al cambiar de versión
Es la diferencia que más pesa a largo plazo, y la fija Odoo en el acuerdo de nivel de servicio de su servicio de actualización, que vale igual para Odoo Online, Odoo.sh y servidor propio.
| Personalización | ¿La convierte el servicio de actualización? | Si no, quién la adapta |
|---|---|---|
| Aplicaciones estándar | Sí | — |
| Lo hecho con Studio | Sí, mientras Studio siga instalado y la suscripción esté activa | — |
| Desarrollos con suscripción de mantenimiento de personalizaciones | Sí | — |
| Módulos sin contrato de mantenimiento, hechos en casa o por terceros, incluidos los partners de Odoo | No | Quien mantiene el módulo |
Fuente: la sección de nivel de servicio de la página de actualizaciones de la documentación de Odoo 20.0, consultada el 17 de octubre de 2026.
Que el servicio convierta lo hecho con Studio no lo exime de pruebas. La documentación de actualizaciones pide probar la base actualizada antes de producción, y su lista incluye las vistas, los reportes, las acciones automatizadas y las acciones de servidor. El contrato deja esa validación del lado del cliente.
Con un módulo hay un paso más, porque la base no avanza sin él: «If your database contains custom modules, it cannot be upgraded until a version of your custom modules is available for the target version of Odoo». La guía de Odoo para bases personalizadas enumera seis pasos: congelar los desarrollos y cuestionarlos frente a lo nuevo, pedir una base de prueba actualizada, lograr que el módulo se instale en una base vacía de la versión destino, después en la base actualizada, probar a fondo con un ensayo y actualizar producción. En Odoo.sh, la actualización de producción arranca con el commit que trae el código adaptado, y si algo falla la plataforma la revierte sola.
Cómo se documenta y se prueba cada uno
| Criterio | Studio | Módulo a medida |
|---|---|---|
| Dónde vive | En la base de datos, como el módulo studio_customization | En archivos de código, normalmente en un repositorio Git |
| Cómo se lleva a otra base | Exportándolo como ZIP e importándolo en una base de la misma versión y con las mismas aplicaciones | Instalando el código del módulo en esa base |
| Cómo se documenta | Con lo que el equipo registre; cada regla de automatización trae una pestaña de notas para su propósito y su funcionamiento | Con el código, su historial de cambios y el manifiesto del módulo, que declara su versión y sus dependencias |
| Cómo se prueba | A mano, en un duplicado neutralizado o en una base de staging | Con pruebas unitarias de Python y de JavaScript, y recorridos que simulan al usuario; en Odoo.sh corren en las ramas de desarrollo |
| De prueba a producción | Se registra lo hecho y se repite en producción | Se fusiona la rama y se actualiza el módulo |
| Quién lo hace | Un usuario funcional capacitado | Un desarrollador con Python |
En Odoo.sh, la penúltima fila es literal. Fusionar una rama de staging con producción sólo lleva el código, y lo que se cambió dentro de la base de staging no pasa a producción. La documentación de Odoo.sh da dos salidas para esos cambios: registrarlos paso a paso y repetirlos en producción, o escribirlos en archivos XML dentro de un módulo de la rama.
Cuándo conviene cada uno
Ninguno de los dos es mejor en abstracto: depende de la necesidad, del alojamiento y de quién va a sostener el cambio.
| Si la necesidad… | Encaja |
|---|---|
| es un campo, una vista, un reporte PDF o una aprobación sobre modelos existentes | Studio |
| es automatizar una acción ante un evento, sin código | Una regla de automatización, con Studio o sin él |
| tiene que correr en una base alojada en Odoo Online | Studio, porque Online no admite módulos a medida |
| la va a sostener un equipo sin perfil de desarrollo | Studio |
| pide lógica que importa librerías, controladores web o componentes de interfaz propios | Un módulo |
| tiene que revisarse como código, con historial y pruebas automáticas | Un módulo |
Cinco preguntas ordenan la decisión:
- ¿Lo resuelve lo estándar? Una opción o una configuración no pide ni Studio ni código, y el servicio de actualización la convierte junto con las aplicaciones estándar.
- ¿Cabe en lo que Studio ofrece y en el alojamiento? Si la base está o estará en Odoo Online, la configuración y Studio son los caminos de personalización que admite.
- ¿Quién lo va a mantener y quién lo va a adaptar en cada versión? Lo hecho con Studio lo convierte el servicio de actualización mientras Studio siga instalado; un módulo lo adapta quien lo mantiene, salvo que tenga contrato de mantenimiento con Odoo.
- ¿Lleva código? Una regla de Studio que ejecuta Python cuenta para el contrato como módulo adicional, y su mantenimiento se cobra aparte, igual que el de un módulo. Entre los dos, entonces, la diferencia está en el alcance y en cómo se prueba cada uno.
- ¿Cómo se va a probar y a documentar? Studio se prueba a mano en una copia neutralizada y se documenta con lo que el equipo registre; un módulo trae pruebas automáticas y el historial del repositorio, y pide quien los escriba.
Studio acerca la personalización a quien opera y deja la conversión de cada versión en manos del servicio de Odoo. Un módulo amplía el alcance y trae las herramientas del software —repositorio, revisión y pruebas— a cambio de un desarrollador que lo sostenga en cada versión. La decisión sale de la necesidad concreta, del alojamiento y de quién va a mantener el cambio.
Preguntas frecuentes
¿Odoo Studio tiene costo?
Studio viene incluido en el plan Custom de Odoo Enterprise. En una base con el plan Standard, instalarlo cambia la suscripción al plan Custom, y en el plan gratuito de una sola aplicación se puede elegir Studio como esa aplicación. El mantenimiento del código Python que se escriba dentro de Studio se cobra aparte.
¿Odoo Studio está en Odoo Community?
No. Las reglas de automatización del módulo base_automation están en el código Community y se configuran sin Studio, pero Studio es parte de Odoo Enterprise: el código Community de Odoo 20 no incluye su módulo, y viene en el plan Custom.
¿Studio funciona en Odoo Online?
Sí, con el plan Custom. Odoo Online admite las personalizaciones que no requieren código propio; lo que no admite son los módulos a medida ni las aplicaciones de la tienda de Odoo.
¿Lo hecho con Studio se pierde al cambiar de versión?
No. El servicio de actualización de Odoo convierte las personalizaciones de Studio mientras Studio siga instalado y la suscripción esté activa. Aun así, la base actualizada se prueba antes de pasar a producción, igual que con cualquier otra personalización.
¿Odoo se puede personalizar sin programar?
Sí, de dos formas: configurando lo estándar —opciones, datos maestros y reglas de automatización— y con Odoo Studio, que agrega campos, vistas, modelos, reportes y reglas de aprobación sin código y requiere el plan Custom. Lo que va más allá, como la lógica que importa librerías o los componentes de interfaz propios, se construye en un módulo a medida.
Por industria
¿Estás decidiendo cómo personalizar tu Odoo? Conoce el servicio de implementación de Odoo o escríbenos.
Fuentes
- Odoo S.A., «Studio», documentación oficial de Odoo 20.0, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ applications/ studio.html - Odoo S.A., «Models, modules, and apps», documentación oficial de Odoo 20.0, Studio, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ applications/ studio/ models_modules_apps.html - Odoo S.A., «Automation rules», documentación oficial de Odoo 20.0, Studio, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ applications/ studio/ automated_actions.html - Odoo S.A., «Upgrade», documentación oficial de Odoo 20.0, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ administration/ upgrade.html - Odoo S.A., «Upgrade a customized database», documentación oficial de Odoo 20.0, desarrolladores, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ developer/ howtos/ upgrade_custom_db.html - Odoo S.A., «Chapter 1: Architecture Overview», documentación oficial de Odoo 20.0, desarrolladores, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ developer/ tutorials/ server_framework_101/ 01_architecture.html - Odoo S.A., «Testing Odoo», documentación oficial de Odoo 20.0, desarrolladores, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ developer/ reference/ backend/ testing.html - Odoo S.A., «Modules», documentación oficial de Odoo 20.0, desarrolladores, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ developer/ reference/ backend/ module.html - Odoo S.A., «Odoo.sh: Getting started», documentación oficial de Odoo 20.0, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ administration/ odoo_sh/ getting_started.html - Odoo S.A., «Odoo.sh: Branches», documentación oficial de Odoo 20.0, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ administration/ odoo_sh/ getting_started/ branches.html - Odoo S.A., «Odoo Online», documentación oficial de Odoo 20.0, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ administration/ odoo_online.html - Odoo S.A., «Odoo Enterprise Subscription Agreement, versión 13 del 24 de septiembre de 2026», documentación oficial de Odoo 20.0, odoo.com/
documentation/ . Consultada el .20.0/ es_419/ legal/ terms/ enterprise.html - Odoo S.A., «Pricing», página pública de precios de Odoo, odoo.com/
pricing . Consultada el . - Odoo S.A., «odoo/tools/safe_eval/evaluation.py», código de Odoo, repositorio odoo/odoo, rama 20.0, github.com/
odoo/ . Consultada el .odoo/ blob/ 20.0/ odoo/ tools/ safe_eval/ evaluation.py - Odoo S.A., «addons/base_automation/__manifest__.py», código de Odoo, repositorio odoo/odoo, rama 20.0, github.com/
odoo/ . Consultada el .odoo/ blob/ 20.0/ addons/ base_automation/ __manifest__.py - Odoo S.A., «Carpeta addons», código de Odoo, repositorio odoo/odoo, rama 20.0, github.com/
odoo/ . Consultada el .odoo/ tree/ 20.0/ addons