Detectar, corregir y contribuir
Detectar un error en Odoo no es algo excepcional: es normal en cualquier software complejo y vivo. La diferencia está en cómo se gestiona ese error.
Ante un comportamiento incorrecto del estándar, existen varias opciones: parchear localmente, crear una personalización o contribuir directamente al producto base. No todas tienen el mismo impacto ni las mismas consecuencias a medio y largo plazo.
En este post explicamos el proceso correcto para abordar un error en Odoo estándar, desde su detección y validación hasta su corrección oficial mediante un Pull Request (una propuesta técnica de cambio) aceptado en el repositorio principal. Para ilustrar el proceso, utilizamos un caso real, sencillo pero representativo, ocurrido en el módulo estándar l10n_es de Odoo 17.
Índice de contenido
- Detectar un error en Odoo core
- Analizar y validar el comportamiento esperado
- Ejemplo práctico: clasificación incorrecta de una cuenta estándar
- Evaluar el impacto real del error
- Decidir la estrategia correcta: corregir el core
- Proponer una corrección en el core mediante Pull Request
- Seguimiento, revisión y validación del PR
- Conclusión: contribuir al core como buena práctica
Detectar un error en el core de Odoo
Al revisar configuraciones estándar en distintos proyectos, se detectó un comportamiento incorrecto en un módulo base de Odoo. No se trataba de una mala configuración ni de un desarrollo personalizado, sino de una definición errónea incluida directamente en el estándar.
Este es el primer punto clave: antes de pensar en una solución, hay que confirmar que el problema está realmente en el core y no en el uso o configuración de parámetros del sistema.
Analizar y validar el comportamiento esperado
Una vez detectado el posible error, el siguiente paso es validar qué debería ocurrir realmente:
- Revisar la lógica funcional o normativa aplicable
- Comprobar si el problema afecta a más de una empresa o escenario.
- Verificar si el error existe en todas las versiones o solo en algunas.
Cuando se cumplen estos puntos, se da la oportunidad de plantear una corrección en el producto base.
Ejemplo práctico: clasificación incorrecta de una cuenta estándar
Como ejemplo real de este proceso, se detectó un error en el módulo estándar l10n_es:
- La cuenta contable [411000 – Acreedores, efectos comerciales a pagar] estaba definida con tipo Activo Corriente (asset_current).
- Según el Plan General Contable español debería clasificarse como Pasivo Corriente (liability_current).
En la siguiente imagen podemos ver la corrección técnica que se realizó:
Tras la aprobación del Pull Request, la corrección quedó integrada directamente en el módulo estándar l10n_es. En el archivo de plantilla contable del core puede verse cómo la cuenta 411000 aparece ya correctamente clasificada como pasivo corriente.
Este caso se utiliza como ejemplo, pero el enfoque es aplicable a cualquier módulo o funcionalidad del core.
Enlace al cambio en el repositorio oficial
Contexto funcional del ejemplo
La cuenta 411000 – Acreedores, efectos comerciales a pagar no representa un derecho de cobro, sino una obligación de pago documentada frente a un tercero. Al tratarse de una deuda pendiente de vencimiento, su naturaleza contable es la de pasivo corriente y no la de activo.
Este tipo de clasificación es especialmente relevante en informes y procesos que dependen de la naturaleza de las cuentas, como el balance de situación y otros análisis contables automáticos.
Evaluar el impacto del error
El error no era meramente teórico. En entornos reales afectaba a la correcta presentación del balance y a distintos informes y procesos que dependen de la clasificación contable de las cuentas.
Decidir la estrategia correcta: corregir el core
Ante este tipo de errores existen varias alternativas, pero no todas son correctas:
- Crear un parche local soluciona solo el funcionamiento de una empresa.
- Personalizar el comportamiento genera deuda técnica.
- Corregir el producto base soluciona el problema de forma estructural.
En este caso, se optó por la vía correcta: proponer una corrección directa en el repositorio oficial de Odoo mediante un Pull Request.
Proponer una corrección en el core
En lugar de parchear localmente, se opta por corregirlo de raíz: crear un Pull Request en el repositorio oficial de Odoo: Pull Request #229214 en GitHub.
La corrección fue:
- Clara y mínima (solo una línea).
- Bien justificada.
- Compatible con versiones anteriores.
Importante: este cambio ya se había realizado previamente en Odoo 18 mediante el PR #222886. La aportación consistió en hacer el backport a Odoo 17, donde el error seguía presente. Esto permite que clientes que aún no migran a la v18 puedan beneficiarse también de la corrección.
Seguimiento y validación del Pull Request
Un Pull Request no termina al abrirlo. Es necesario:
- Seguir activamente la revisión.
- Responder a comentarios del equipo de Odoo.
- Ajustar la propuesta si es necesario.
Gracias a este proceso, el PR fue validado y aprobado oficialmente en Odoo 17.
Conclusión
Este caso demuestra que cuando se detecta un error en Odoo, es mejor contribuir al producto base que personalizar sin control. Resolver un problema de forma estructural beneficia no solo a tu cliente, sino a toda la comunidad. Como partners, tenemos también la responsabilidad de mantener y mejorar el ecosistema Odoo. Contribuir al core no es solo una cuestión técnica, sino una forma responsable de trabajar con el producto y de fortalecer su ecosistema a largo plazo.
Mejorar Odoo es responsabilidad de todos
Detección de errores y propuestas de mejora en Odoo con Sygel