Desarrollo Odoo a medida: personalización y módulos propios

Cuando una empresa mexicana dice que necesita desarrollo Odoo, casi nunca se trata de programar por programar. Lo que suele existir es un proceso propio —una forma de cotizar, de surtir, de aprobar compras, de repartir comisiones— que el sistema estándar no refleja del todo. La pregunta útil no es «¿se puede hacer?» (casi siempre se puede), sino «¿cuál es la manera más barata de sostenerlo durante años?».

Esta página ordena las opciones de personalización de Odoo, de la más ligera a la más pesada, y explica qué consecuencias tiene cada una sobre las actualizaciones, la licencia y el mantenimiento.

Las cuatro capas de personalización en Odoo

Conviene pensar en escalones. Cada uno cuesta más que el anterior, no solo al construirlo sino al conservarlo.

La regla práctica: suba un escalón solo cuando el anterior haya fallado de forma demostrable. Es sorprendente cuántos «desarrollos» pedidos al inicio de un proyecto desaparecen cuando alguien conoce bien el estándar.

Primer escalón: exprimir el estándar

Antes de hablar de código, revise si el requerimiento ya está resuelto en una aplicación que no ha activado. Un módulo estándar bien configurado cubre, por ejemplo, rutas de reabastecimiento, reglas de precios por cliente o varios almacenes. Para ver qué trae cada área consulte los módulos de Odoo y, según su caso, las páginas de contabilidad y finanzas o de inventario y compras.

Un buen integrador hace aquí un ejercicio incómodo pero rentable: por cada requerimiento «especial», pregunta qué problema de negocio resuelve y qué pasaría si se adoptara el flujo estándar. A veces el proceso de la empresa es una costumbre heredada de otro sistema, no una ventaja competitiva. Otras veces sí lo es, y entonces vale la pena protegerlo con una personalización.

Segundo escalón: Odoo Studio

Odoo Studio permite personalizar sin código campos, vistas, modelos, aplicaciones, reglas de automatización, webhooks, reportes PDF, reglas de aprobación y reglas de seguridad. Para una pyme que quiere añadir un campo de «agente aduanal» en los pedidos, una aprobación de gastos por monto o un reporte con su propio formato, es la vía más rápida.

Hay un detalle de licencia que sorprende a muchos: la fórmula Custom incluye Odoo Studio, junto con el multi-sociedad y el acceso a la API externa, y instalar Studio sobre una base en fórmula Standard provoca un cambio automático a Custom. En contrato anual se genera un pedido complementario con plazo de 30 días; en contrato mensual, el cambio se aplica en el siguiente ciclo de facturación.

En números publicados por Odoo, la diferencia entre fórmulas es de 24,90 EUR por usuario y mes en Standard frente a 44,90 EUR en Custom (con descuentos iniciales válidos durante 12 meses). Antes de decir «lo hacemos con Studio», calcule el efecto sobre su número de usuarios; el detalle general está en la página de precios de Odoo. Recuerde también que solo cuentan como usuarios de pago quienes tienen acceso al backend: los usuarios de portal, como clientes y proveedores, no se cuentan.

Límites de Studio

Studio es excelente para estructura y presentación, y limitado para lógica. Si necesita un cálculo de comisiones con reglas encadenadas, una conciliación particular o una validación que consulta varios modelos a la vez, el siguiente escalón está más cerca de lo que parece. Otro riesgo es el desorden: cuando varias personas modifican vistas sin registro de cambios, la base se vuelve difícil de auditar. Asigne a una sola persona la responsabilidad de esos ajustes.

Tercer escalón: extensiones ya existentes

Odoo anuncia 50 aplicaciones principales y una comunidad que ha aportado más de 50 000 aplicaciones adicionales. Esa cifra explica por qué, ante una necesidad, casi siempre existe algo parecido. También explica el riesgo: la calidad es muy desigual.

Antes de instalar una extensión de terceros, verifique:

• Quién la mantiene y si sigue las versiones nuevas de Odoo.
• Su licencia, compatible con la de la edición que usa. Los desarrolladores pueden distribuir módulos bajo la licencia que elijan siempre que sea compatible con la de la edición de origen: LGPLv3 en Community, con las restricciones de Enterprise en esa edición.
• Si el código es legible y revisable, no un paquete opaco.
• Cuánto toca del estándar: una extensión que sobrescribe vistas y modelos centrales es una deuda técnica disfrazada.

Para México, las extensiones de localización fiscal merecen atención especial. Todo lo relativo a CFDI 4.0, al PAC y a la contabilidad electrónica del SAT se revisa con más rigor que cualquier otro módulo; la página sobre Odoo en México y las guías de CFDI 4.0 y de contabilidad electrónica explican qué debe cubrir la localización antes de pensar en cualquier desarrollo adicional.

Cuarto escalón: el módulo a medida

El desarrollo específico en Odoo se hace en Python, con vistas definidas en XML y datos en PostgreSQL. Un módulo propio puede agregar modelos, modificar comportamientos de los existentes, crear reportes, automatizar procesos o exponer servicios a otros sistemas. Para integrar con sistemas externos, la documentación de Odoo presenta JSON-2 como la API externa actual (con claves de API, derechos de acceso, selección de base de datos y transacciones) y considera históricas a XML-RPC y JSON-RPC, con una guía de migración. Esa API es una función de la fórmula Custom.

Cuándo sí conviene

• El proceso es parte de su ventaja competitiva y ninguna configuración lo reproduce.
• Se repite a diario con volumen suficiente como para que el ahorro de tiempo justifique el costo.
• Se necesita una integración con un sistema propio o poco común; en ese caso revise primero la página de integraciones de Odoo.
• Un sector con reglas muy concretas exige cálculos o controles que nadie ofrece listos.

Cuándo no conviene

• Cuando el requerimiento reproduce el sistema anterior «tal cual» por comodidad.
• Cuando existe un módulo estándar o una extensión mantenida que cubre la mayor parte de la necesidad: adaptar el proceso suele costar menos que mantener código.
• Cuando nadie en la empresa podrá explicar, dentro de un tiempo, por qué existe ese módulo.

Qué ocurre con las actualizaciones

Esta es la pregunta que más cuesta responder bien al inicio y más dinero cuesta ignorar. Odoo evoluciona por versiones; cada una puede cambiar estructuras internas. El código propio que se apoya en los mecanismos de extensión previstos suele adaptarse con poco esfuerzo. El que modifica el comportamiento central de forma invasiva obliga a revisar, probar y a veces reescribir.

Tres consecuencias prácticas:

1. Cada línea de código propio es una línea que usted mantiene. Un desarrollo no se paga una vez: se paga en cada migración.
2. Las bases con mucho código a medida migran más lento, porque cada módulo debe probarse contra la versión nueva. Lo explica con detalle la página de migración de Odoo.
3. La edición importa. Odoo Community está bajo licencia LGPLv3; Enterprise usa la licencia Odoo Enterprise Edition v1.0, que solo se puede utilizar con una suscripción vigente para el número correcto de usuarios. Un módulo a medida debe diseñarse sabiendo en cuál de las dos corre.

Si ya tiene una base con desarrollos acumulados y dudas sobre su estado, un audit o rescate de Odoo permite medir la deuda antes de decidir si se limpia, se rehace o se migra.

Buenas prácticas que evitan problemas años después

Mantenerse en el estándar. Extender es mejor que reemplazar. Un módulo que añade un campo y una validación es más sano que otro que sobrescribe una vista completa.

Documentar de verdad. Cada desarrollo debe entregarse con: el problema de negocio, la alternativa estándar descartada, el comportamiento esperado, los modelos que toca y las pruebas realizadas. Sin eso, el siguiente desarrollador empieza de cero.

Probar fuera de producción. Toda modificación pasa por una base de pruebas con datos representativos antes de llegar a su operación. Para facturación, nómina o inventario, el ensayo incluye los casos incómodos: devoluciones, cancelaciones de CFDI, ajustes y cierres de mes.

Versionar el código. El código debe vivir en un repositorio al que su empresa tenga acceso, no solo en la máquina del proveedor.

Dejar un responsable interno. Alguien de su lado, aunque no programe, debe entender qué hace cada módulo propio y aprobar los cambios.

Pensar en el soporte. Un desarrollo sin quien lo atienda es un riesgo operativo. Verifique cómo se organiza el soporte y mantenimiento de Odoo después de la puesta en producción.

Cómo evaluar a un desarrollador o a un integrador Odoo

Al elegir quién escribirá su código, estas preguntas separan a quien conoce Odoo de quien solo conoce programación:

• ¿Pregunta primero por el proceso de negocio o se lanza a proponer código?
• ¿Sabe decir, sin dudar, qué parte del requerimiento se resuelve con el estándar?
• ¿Explica el efecto del desarrollo en las futuras actualizaciones, por escrito?
• ¿Entrega documentación y acceso al repositorio?
• ¿Tiene experiencia con la localización mexicana, es decir, con CFDI, PAC y contabilidad electrónica, y no solo con proyectos en otros países?
• ¿Puede mostrar un proyecto parecido, con una referencia que usted pueda contactar?
• ¿Acepta un plan de pruebas y una entrega por etapas?

Desconfíe de quien promete adaptarlo todo sin cuestionar nada. Cuanto más rápido dice «sí» un proveedor, menos probable es que haya entendido su operación. La guía para elegir un integrador ERP y la página específica sobre cómo elegir un integrador Odoo amplían estos criterios.

Cómo le ayudamos

Integrador ERP no desarrolla ni implanta: es un servicio gratuito que lo pone en contacto con un integrador adecuado a su proyecto. Usted describe su necesidad, incluidos los procesos que cree que exigen desarrollo a medida, y recibe contacto de integradores que ya trabajan con Odoo. La decisión de contratar y las condiciones se acuerdan directamente con ellos. Si quiere ver el procedimiento paso a paso, está explicado en cómo funciona la puesta en contacto.

Si todavía compara sistemas y la capacidad de personalización es un criterio, también puede revisar la comparativa entre Odoo y Business Central antes de decidir.

Los nombres de software mencionados son marcas de sus respectivos editores y se citan únicamente a título informativo. Este sitio es independiente y no está afiliado a ningún editor.