Todo proyecto de Odoo llega tarde o temprano a la misma pregunta: el flujo estándar se acerca, pero no es exactamente lo que quiere el negocio. ¿Conviene cambiar un ajuste, abrir Odoo Studio o pedir a un desarrollador que escriba un módulo personalizado? La respuesta tiene consecuencias a largo plazo en costo, estabilidad y, sobre todo, en las actualizaciones.
En 1CBMS seguimos una regla sencilla en cada implementación: primero la configuración, luego Studio y después los módulos personalizados. Cada peldaño de esa escalera agrega flexibilidad, pero también agrega algo que el negocio debe asumir y mantener durante toda la vida del sistema.
Una nota sobre las fuentes: este artículo se basa en la documentación oficial de Odoo para la versión 19.0. Los menús y las opciones pueden variar entre versiones, ediciones y tipos de alojamiento, así que confirme siempre el comportamiento en una base de datos de prueba antes de modificar producción.
Capa uno: la configuración antes que nada
Odoo incluye una gran cantidad de ajustes, opciones y registros configurables en cada aplicación. Muchas solicitudes que parecen personalizaciones son en realidad funciones estándar que todavía no se han activado, como pasos adicionales en un flujo, diseños de documentos o campos opcionales que aparecen al habilitar una función.
Antes de redactar cualquier especificación para Studio o para código, revise lo siguiente con los usuarios clave del proceso:
- Revise la página de Ajustes de cada aplicación involucrada y lea qué habilita cada opción.
- Verifique si el requisito se cubre con registros configurables como etapas, etiquetas, equipos, tipos de operación o plantillas de correo electrónico.
- Use los ajustes de diseño de documentos de la empresa para logotipos, colores, fuentes y pies de página en lugar de editar las plantillas de reportes.
- Pregunte si el negocio puede adaptar su proceso al flujo estándar, porque los flujos estándar los prueba y actualiza Odoo.
La configuración es la capa más económica de mantener. Forma parte del producto estándar, se conserva en el proceso de actualización y no crea una base de código aparte que alguien deba mantener.
Capa dos: lo que puede hacer Odoo Studio
La documentación de Odoo describe Studio como un conjunto de herramientas para personalizar Odoo sin conocimientos de programación. Se abre con el ícono Alternar Studio mientras está en la aplicación y el modelo que desea cambiar, y se cierra con el botón Cerrar.
Según la documentación oficial, Studio abarca estas áreas:
- Campos: campos simples como texto, entero, decimal, monetario, fecha, casilla de verificación, selección, archivo e imagen, y campos relacionales como Many2One, One2Many, Líneas, Many2Many, Etiquetas y campos relacionados.
- Vistas: vistas de formulario, actividad, búsqueda, kanban, lista, mapa, calendario, cohorte, Gantt, pivote y gráfica.
- Modelos y aplicaciones: nuevos modelos creados desde cero, con funciones sugeridas como chatter, etapas de flujo, etiquetas, archivado y líneas para agilizar la creación.
- Reglas de automatización: disparadores basados en actualizaciones de valores, eventos de correo electrónico, condiciones de tiempo, creación o eliminación de registros, cambios en la interfaz y webhooks externos.
- Reglas de aprobación: pasos de visto bueno vinculados a botones, con aprobadores definidos como usuarios, grupos o ambos. Studio también abarca webhooks y reglas de seguridad.
- Reportes PDF: edición de texto estático e inserción de campos dinámicos, tablas, columnas e imágenes en las plantillas de reportes; tenga en cuenta que editar el encabezado o el pie de página de un reporte afecta a todos los reportes.
Cuando modifica una vista arrastrando y soltando, Studio crea automáticamente la vista heredada y el XPath correspondientes en lugar de sobrescribir la vista estándar. Todo el trabajo de Studio se agrupa en un módulo llamado studio_customization en su base de datos, que puede exportarse como archivo ZIP e importarse en otra base de datos.
Studio es una aplicación de Odoo Enterprise. La página oficial también señala que instalar Studio en una base de datos con el plan de precios Estándar implica pasar al plan Personalizado, así que verifique el impacto comercial con su gerente de cuenta de Odoo antes de activarlo. Las bases de datos Community no incluyen Studio; en ellas, todo lo que va más allá de la configuración se hace mediante ajustes técnicos en modo de desarrollador o mediante módulos.
Capa dos (continuación): los límites de Studio
Studio es potente, pero la propia documentación señala varios límites y riesgos que todo proyecto debe respetar:
- El nombre técnico de un campo no puede cambiarse en Studio después de crearlo, y los campos personalizados deben conservar al menos el prefijo x_, mientras que los campos de Studio usan x_studio_.
- La vista de actividad y los bloques condicionales de los reportes solo pueden modificarse editando el XML, lo que requiere el modo de desarrollador.
- Se desaconseja editar directamente las vistas estándar o heredadas, porque esos cambios se restablecerían y perderían durante las actualizaciones de versión o de módulos.
- Odoo recomienda encarecidamente duplicar un reporte estándar y editar la copia, y advierte que modificar directamente el XML de un reporte puede causar problemas durante las actualizaciones.
- La acción Ejecutar código de las reglas de automatización ejecuta Python, y la documentación indica que el mantenimiento del código personalizado no está incluido en los planes Estándar ni Personalizado y genera cargos adicionales.
- Los webhooks deben diseñarse con un desarrollador o un perfil técnico, porque los webhooks mal configurados pueden afectar el funcionamiento de la base de datos.
- Las personalizaciones de Studio exportadas solo pueden importarse en una base de datos de la misma versión de Odoo con las mismas aplicaciones y módulos instalados.
En la práctica, Studio es ideal para la captura de datos, el diseño, la automatización sencilla y las aprobaciones. Se vuelve riesgoso cuando se usa para ocultar programación real dentro de ediciones de XML o acciones Ejecutar código que nadie documenta.
Capa tres: cuándo está justificado un módulo personalizado en Python
Un módulo personalizado es una base de código independiente que amplía Odoo mediante modelos, vistas, seguridad, archivos de datos y lógica en Python, construido con el mismo framework que Odoo usa para sus propias aplicaciones. Es la herramienta adecuada cuando el requisito va más allá de lo que la configuración y Studio pueden expresar de forma limpia.
Las situaciones típicas en las que recomendamos un módulo personalizado incluyen:
- Reglas de negocio, cálculos o restricciones complejos que necesitan pruebas automatizadas y control de versiones.
- Integraciones con sistemas externos que requieren un manejo sólido de errores, reintentos y registros.
- Cambios en la lógica de negocio estándar, como la forma en que se validan los documentos o se calculan los valores, y no solo en cómo se muestran.
Aquí el alojamiento importa. La documentación oficial indica que Odoo Online no es compatible con módulos personalizados ni con módulos de la Odoo Apps Store. Los módulos personalizados requieren Odoo.sh o una instalación on-premise, así que la decisión de alojamiento y la estrategia de personalización deben tomarse juntas.
Impacto de cada opción en las actualizaciones
- Configuración: forma parte del producto estándar y se migra con el proceso de actualización estándar.
- Studio: los servicios de actualización descritos en la documentación de Odoo incluyen la actualización de todas las personalizaciones creadas con la aplicación Studio, siempre que Studio esté instalado y su suscripción esté activa.
- Módulos personalizados: una base de datos con módulos personalizados no puede actualizarse hasta que exista una versión de esos módulos para la versión de Odoo de destino, y hacerlos compatibles es responsabilidad de quien mantiene el módulo.
La guía de Odoo para actualizar una base de datos personalizada recomienda congelar el desarrollo, verificar qué funciones personalizadas ya ofrece el estándar, lograr que cada módulo se instale sin errores en una base de datos vacía de la versión de destino, escribir scripts de actualización para los modelos, campos e identificadores externos renombrados, y ensayar la actualización antes de tocar producción.
Sea cual sea la capa, pruebe a fondo la base de datos actualizada. La documentación aconseja probar los flujos de negocio de principio a fin, incluidas integraciones, acciones automatizadas, acciones de servidor y reportes, y recuerda que las bases de datos de prueba están neutralizadas, con las acciones planificadas y los correos salientes desactivados.
Gobernanza: mantener las personalizaciones bajo control
Las personalizaciones rara vez fallan el primer día. Fallan años después, cuando nadie recuerda por qué existe un campo ni quién escribió una regla de automatización. Un modelo de gobernanza ligero lo evita.
- Lleve un registro de personalizaciones que liste cada campo de Studio, cambio de vista, regla de automatización, regla de aprobación, reporte y módulo personalizado, con su responsable y su justificación de negocio.
- Haga todos los cambios primero en una base de datos de prueba o de preproducción y luego páselos a producción mediante un proceso controlado.
- Limite Studio y el modo de desarrollador a administradores capacitados; la propia documentación advierte que algunas herramientas de desarrollador son avanzadas y conllevan riesgos.
- Revise el registro antes de cada actualización y retire las personalizaciones que la nueva versión ya cubre de forma estándar.
- Mantenga el código de los módulos personalizados en control de versiones con pruebas, y asegúrese de que exista un acuerdo de mantenimiento para él.
Una matriz de decisión que puede aplicar en los talleres
Cuando surge un nuevo requisito, recorremos estas preguntas en orden y nos detenemos en la primera capa que lo resuelve.
- ¿Un ajuste estándar, un registro configurable o un cambio de proceso cubre la necesidad? Use la configuración.
- ¿Es un campo nuevo, un cambio en el diseño de una vista, una automatización sencilla, un paso de aprobación o un cambio de redacción en un reporte? Use Studio.
- ¿Necesita lógica en Python, pruebas automatizadas, una integración compleja o reutilizarse en varias bases de datos? Use un módulo personalizado.
- ¿La base de datos está en Odoo Online? Manténgase dentro de la configuración y Studio, o planifique primero el paso a Odoo.sh o a on-premise.
Cómo puede ayudarle 1CBMS
1CBMS ayuda a empresas de Egipto e Irak a diseñar soluciones con Odoo 19 Enterprise que se mantienen cerca del estándar. Realizamos talleres de análisis de brechas (fit-gap) para separar la configuración de las brechas reales, construimos personalizaciones disciplinadas con Studio, desarrollamos y mantenemos módulos personalizados cuando de verdad se necesitan, y preparamos registros de personalizaciones y planes de prueba de actualización para que su sistema siga siendo mantenible. Contáctenos a través de www.1cbms.com para revisar sus personalizaciones actuales o planificar una nueva implementación.