Casi todas las peticiones que llegan a un partner de Odoo se pueden resolver de tres formas: configurando el estándar, usando Odoo Studio o escribiendo un módulo en Python. Las tres funcionan. Lo que cambia es cuánto te costará mantenerlas vivas dentro de dos versiones.
Primera opción: el estándar
Antes de personalizar nada, merece la pena preguntarse si el proceso de la empresa es realmente especial o simplemente es el que se hacía con el software anterior. Muchos requisitos «imprescindibles» desaparecen cuando alguien explica cómo lo resuelve Odoo de serie.
El estándar tiene una ventaja que ninguna personalización puede igualar: se migra solo. Odoo mantiene la compatibilidad de sus propias funcionalidades entre versiones. Lo que no has tocado, no se rompe.
Segunda opción: Odoo Studio
Studio cubre campos nuevos, vistas modificadas, informes, reglas de automatización y flujos de aprobación sin escribir código. Es la herramienta adecuada para la mayoría de las diferencias reales entre empresas.
Tiene un límite importante que conviene conocer: Studio no admite Python. Sus personalizaciones se guardan como datos, no como código versionado, y quedan fuera de los ciclos de actualización automática de módulos. Después de un upgrade mayor hay que revalidarlas a mano — es rápido, pero alguien tiene que hacerlo, y por eso está incluido en nuestro nivel de soporte Low-Code.
Tercera opción: un módulo Python
Hay casos que no se resuelven de otra forma: lógica de negocio compleja, cálculos propios, integraciones con protocolos exóticos o rendimiento sobre volúmenes grandes. Entonces se escribe un módulo, y con él llega todo lo que conlleva tratar el software como software: repositorio Git, entorno de staging, revisiones y despliegue controlado.
Es la opción más potente y la más cara de mantener. Cada versión de Odoo introduce cambios en la API que obligan a revisar el código. En Odoo 19, por ejemplo, varias construcciones habituales dejaron de funcionar en silencio: las restricciones SQL declaradas al modo antiguo simplemente se ignoran, y las vistas de lista cambiaron de etiqueta. Un módulo sin mantenimiento no da un error claro el día de la migración: da un comportamiento raro tres semanas después.
Un criterio práctico
- ¿Lo hace el estándar aunque sea de otra manera? Usa el estándar.
- ¿Es un campo, una vista, un informe o una automatización? Studio.
- ¿Requiere lógica que no se expresa con condiciones simples, o una integración a medida? Módulo Python.
Y una regla que aplicamos siempre: si la personalización no ahorra tiempo medible o no evita un error caro, no se hace. Cada una de ellas es una factura aplazada al día del upgrade.