Más de 200 repositorios en GitHub y miles de módulos: ese es el volumen que mantiene la comunidad de OCA para Odoo Community, y sin pagar licencia por ninguno. La cifra engaña, porque no todos los módulos llegan a tu versión de Odoo ni reciben el mismo cuidado. Si ya usas Community y quieres ampliar funciones sin pasar a Enterprise, necesitas un criterio para separar lo fiable de lo abandonado.
OCA (Odoo Community Association) es una organización sin ánimo de lucro, independiente de Odoo S.A. En esta guía repasamos cómo evaluar un módulo, cómo instalarlo con Docker y cuándo conviene no usarlo.
Puntos clave
OCA es independiente de Odoo S.A.; no hay soporte oficial de Odoo.
Los módulos son gratuitos (AGPL-3), pero mantenerlos tiene coste.
Comprueba rama, actividad, pruebas CI y mantenedores antes de instalar.
Que exista en una rama antigua no garantiza que exista en tu versión.
Con Docker, monta los repositorios OCA y añádelos a addons_path.
Menos módulos facilitan cada actualización de versión.
¿Qué es OCA y qué relación tiene con Odoo?
OCA es una asociación sin ánimo de lucro que coordina el desarrollo de módulos open source para Odoo Community. El código vive en GitHub, bajo la organización OCA, y cualquier desarrollador o empresa puede proponer cambios. Odoo S.A. participa como miembro, pero no es su propietaria ni da soporte a estos módulos.
Esa distinción es importante en la práctica. Si un módulo OCA falla, no abres un ticket a Odoo: lo reportas como issue en el repositorio, o lo arreglas tú o un proveedor.
Odoo Community, Enterprise y OCA: tres cosas distintas
Odoo Community es la edición libre, con licencia LGPL-3. Odoo Enterprise es la edición de pago, con módulos propietarios y soporte oficial. OCA no es ninguna de las dos: es un conjunto de módulos adicionales que se instalan encima de Community.
Por eso la respuesta a «¿OCA es lo mismo que Odoo Community?» es no. Community es el producto base; OCA añade funciones que Community no trae, como conciliación avanzada, informes, utilidades de servidor o localizaciones.
Licencia y coste real
Los módulos OCA usan sobre todo la licencia AGPL-3 (algunos, LGPL). Puedes descargarlos, modificarlos y usarlos en tu empresa sin pagar licencia. La AGPL obliga a ofrecer el código modificado a los usuarios que accedan al sistema por red, algo que afecta sobre todo a quien revende desarrollos.
Gratuito, sin embargo, no significa sin coste. Pagas la integración, las pruebas, la migración entre versiones y la reparación cuando algo se rompe. Ese coste es el que decide si un módulo compensa, y lo desarrollamos más abajo.
OCA es una asociación sin ánimo de lucro cuyo objetivo es promover el uso de Odoo y apoyar el desarrollo colaborativo de sus módulos open source.
Criterios para evaluar un módulo OCA antes de instalarlo
Un módulo es fiable si está publicado en tu rama de Odoo, tiene actividad reciente, pasa las pruebas automáticas y cuenta con mantenedores identificados. Basta revisar cuatro o cinco señales en su repositorio, en unos diez minutos, para evitar la mayoría de los problemas posteriores.
La tabla resume qué mirar y cómo interpretarlo.
Criterio
Dónde se comprueba
Señal buena
Señal de alarma
Rama de tu versión
Selector de ramas en GitHub (por ejemplo, 17.0)
Existe la carpeta del módulo
Solo aparece en ramas anteriores
Actividad
Pestaña Commits y Pull requests
Cambios en los últimos 6-12 meses
Último commit de hace más de dos años
Pruebas CI
Marca verde en el último commit
Tests pasan en GitHub Actions
Fallos sin resolver
Mantenedores
Campo `maintainers` del manifest
Uno o más nombres
Campo vacío
Estado
Campo `development_status`
Production/Stable o Beta
Alpha o sin indicar
Dependencias
Campo `depends` del manifest
Pocas, todas en OCA o Odoo
Muchas, de repositorios sin mantener
Compatibilidad por versión
OCA mantiene una rama por versión de Odoo (16.0, 17.0, 18.0). Un módulo puede existir en la 14.0 y no haber sido migrado a la 17.0. Nunca des por hecho que un módulo de una rama antigua existe en la tuya. Comprueba la carpeta en la rama exacta antes de planificar nada.
También conviene mirar si hay un pull request de migración abierto. Si lo hay y lleva meses sin revisión, el módulo no llegará pronto.
Actividad, mantenedores y estado
La actividad no se mide solo por la fecha del último commit. Un módulo pequeño y estable puede no cambiar durante un año y seguir funcionando. Lo que importa es que los issues reciban respuesta y que alguien revise las migraciones.
El campo `maintainers` del archivo `__manifest__.py` indica quién se compromete a cuidarlo. Si está vacío, nadie tiene esa responsabilidad formal. El campo `development_status` completa la imagen: Alpha significa experimental, Beta usable con cautela y Production/Stable fiable.
Pruebas CI y Runboat
Cada pull request en OCA pasa por integración continua: tests automáticos, comprobaciones de estilo con pre-commit y cobertura. Un commit con marca verde indica que el módulo se instala y que sus tests básicos pasan en esa rama.
Además, OCA usa Runboat, un sistema que levanta una instancia de Odoo con el módulo instalado a partir de un pull request o una rama. Desde el propio repositorio puedes abrir esa instancia y probar el módulo sin instalar nada en tu servidor. Úsalo siempre que sea posible antes de tocar producción.
¿Qué módulos OCA son útiles para una pyme en España?
Los repositorios más útiles para una pyme española son los de localización (`l10n-spain`), contabilidad (`account-financial-tools`, `account-reconcile`), informes (`reporting-engine`) y utilidades de servidor (`server-tools`, `server-ux`). Cubren carencias que Community no resuelve de serie.
Localización española: l10n_es
El repositorio `l10n-spain` agrupa los módulos `l10n_es_` que Community no incluye completos. Entre ellos están los modelos fiscales (303, 111, 347, 349), el SII, la facturación electrónica FACe y Facturae, y el soporte de remesas SEPA para cobros y pagos. Para una empresa en Barcelona que presente impuestos a la Agencia Tributaria, es probablemente el repositorio más relevante.
Aquí la fiabilidad depende de la normativa. Cuando cambia un formato fiscal, el módulo debe actualizarse; por eso comprobamos la actividad del repositorio antes de apoyar un cierre trimestral en él. Si tu gestoría te exige un modelo concreto, verifica que el módulo lo cubre en tu versión, no en otra.
Contabilidad, informes y utilidades
En contabilidad, `account-financial-reporting` ofrece balances y libros mayores más completos, y `account-reconcile` mejora la conciliación bancaria. En `reporting-engine` encuentras generadores de informes en hoja de cálculo. En `server-tools` hay módulos para tareas de administración, como programar la limpieza de adjuntos o auditar cambios.
Cuándo conviene no usar un módulo OCA
No uses un módulo si cumple alguna de estas condiciones:
Solo existe en versiones que ya no tienen soporte.
Tiene una función que Odoo Enterprise o una versión nueva de Community ya incorpora de serie.
Depende de muchos otros módulos sin mantener.
Toca el cálculo fiscal y no tiene actividad en el último año.
Resuelve una comodidad menor que no justifica el coste de migrarlo cada año.
Si el módulo es cosmético, a veces sale más barato adaptar el proceso que mantener el código.
OCA frente a la App Store de Odoo: diferencias prácticas
La App Store de Odoo reúne módulos de terceros, gratuitos y de pago, publicados por empresas o autores individuales. OCA es un proyecto comunitario con reglas de calidad comunes. Ambos pueden ser buenos, pero el control de calidad es distinto.
En OCA, el código pasa revisión de otros desarrolladores, tests y reglas de estilo antes de fusionarse. En la App Store, la calidad depende del autor: encuentras módulos excelentes y otros sin actualizar desde hace años. Además, un módulo de pago te da un proveedor al que reclamar, mientras que en OCA el soporte es comunitario o lo contratas aparte.
Para decidir, usa esta regla práctica. Si existe un equivalente en OCA con actividad reciente, empieza por ahí. Si necesitas un compromiso de soporte con un responsable claro, valora un módulo de pago o un desarrollo a medida con contrato.
¿Funcionan los módulos OCA con Odoo Enterprise?
Técnicamente muchos sí, porque Enterprise se construye sobre Community. Sin embargo, no está garantizado: algunos módulos OCA sustituyen funciones que Enterprise ya cubre y pueden entrar en conflicto con sus módulos propietarios. Si usas Enterprise, prueba cada módulo en una copia de la base de datos antes de instalarlo, y recuerda que el soporte oficial de Odoo no cubre código OCA.
Cómo instalar módulos OCA con Docker paso a paso
La instalación consiste en descargar el repositorio OCA de tu rama, montarlo como volumen en el contenedor, añadir su ruta a `addons_path` y actualizar la lista de aplicaciones. Con Docker queda reproducible y se puede repetir idéntica en pruebas y producción.
Estos son los pasos que seguimos:
Crea en el servidor un directorio para los addons externos, por ejemplo `/opt/odoo/oca`.
Clona solo la rama que necesitas: `git clone --depth 1 -b 17.0 https://github.com/OCA/l10n-spain.git`. El parámetro `--depth 1` evita descargar todo el historial.
Monta esa carpeta como volumen en `docker-compose.yml`, por ejemplo `/opt/odoo/oca/l10n-spain:/mnt/extra-addons/l10n-spain`.
Añade la ruta a `addons_path` en `odoo.conf`, separada por comas de las rutas existentes.
Instala las dependencias de Python que pida el repositorio. Muchos incluyen un `requirements.txt`; instálalo en una imagen personalizada, no a mano dentro del contenedor.
Reinicia el contenedor, activa el modo desarrollador y pulsa Actualizar lista de aplicaciones.
Instala el módulo primero en una base de datos de pruebas, y solo después en producción.
Imagen propia y dependencias
El error habitual es instalar paquetes de Python con `pip` dentro del contenedor en marcha. Se pierden al recrearlo. Define un `Dockerfile` que parta de la imagen oficial de Odoo, copie el `requirements.txt` y lo instale. Así cada despliegue incluye todo lo necesario.
Fija también las versiones: usa una etiqueta concreta de la imagen y un commit concreto de cada repositorio OCA. Si siempre descargas la última versión de la rama, una actualización de un módulo puede romperte producción sin aviso.
Copias de seguridad antes de cada cambio
Haz un volcado de PostgreSQL (`pg_dump`) y una copia del filestore antes de instalar o actualizar cualquier módulo. Desinstalar un módulo no siempre revierte los datos que creó, y a veces la única vuelta atrás es restaurar. En Synergia desplegamos Odoo en servidores dedicados con Docker y PostgreSQL, y esta copia previa forma parte de cualquier cambio en producción.
El coste real: mantenimiento y actualización de versión
El coste de un módulo OCA aparece cuando cambias de versión de Odoo. Odoo publica una versión mayor cada año, y cada módulo externo debe estar migrado a la nueva rama antes de que tú actualices. Si no lo está, tienes tres opciones: esperar, migrarlo tú o prescindir de él.
Qué ocurre con un módulo al actualizar
Migrar un módulo pequeño puede llevar unas horas de desarrollo. Uno grande, con vistas, informes y lógica fiscal, puede costar varios días. Como orden de magnitud, con tarifas habituales de consultoría de 50 a 90 € por hora, ocho horas suponen entre 400 y 720 € por módulo. Son cifras orientativas: dependen de la complejidad y del estado del código.
Si el módulo tiene mantenedores activos, es probable que la migración llegue gratis a la rama nueva en algunos meses. Por eso conviene mirar la rama siguiente y los pull requests abiertos antes de decidir cuándo actualizar.
Menos módulos, actualizaciones más sencillas
Cada módulo añadido es una dependencia que cuidar. Cuarenta módulos externos significan cuarenta posibles bloqueos el día de la migración. Antes de instalar uno, pregúntate si la función justifica ese compromiso anual.
Una política sencilla ayuda: mantén una lista documentada de módulos externos, con su repositorio, su rama, el motivo de uso y la persona responsable. En la próxima actualización sabrás exactamente qué revisar.
Errores comunes al usar módulos comunitarios
Los fallos más frecuentes no son técnicos, sino de criterio. Estos son los que más complican la vida a una pyme:
Creer que OCA tiene soporte oficial de Odoo. No lo tiene; el soporte es comunitario o contratado a un proveedor.
Instalar sin mirar la rama. El módulo del tutorial puede no existir en tu versión.
Acumular módulos «por si acaso». Cada uno encarece la siguiente migración.
Probar directamente en producción. Usa una copia de la base de datos o Runboat.
Ignorar las dependencias. Un módulo que depende de otros sin mantener hereda su abandono.
Olvidar fijar versiones. Un `git pull` sin control puede cambiar el comportamiento de un día para otro.
Evitarlos no exige mucho tiempo, solo disciplina: revisar, probar en copia, documentar y actualizar con calendario.
Conclusión
Elige un módulo OCA si existe en tu rama, tiene actividad reciente, pasa CI y cubre una necesidad que justifica su mantenimiento. Descártalo si solo vive en versiones antiguas o resuelve una comodidad menor. Antes de instalar nada, abre su repositorio, revisa esos cuatro puntos y pruébalo en una copia. Si necesitas apoyo para alojarlo y actualizarlo con Docker, Synergia puede encargarse del despliegue.
Preguntas frecuentes
¿Qué es OCA en Odoo?
OCA es la Odoo Community Association, una organización sin ánimo de lucro que mantiene cientos de módulos open source para Odoo Community en GitHub. No pertenece a Odoo S.A. y funciona con desarrollo colaborativo y revisión entre pares.
¿Los módulos de OCA son gratuitos?
Sí, se distribuyen con licencia AGPL-3 o LGPL y no tienen coste de licencia. Aun así, tienes costes de instalación, pruebas, mantenimiento y migración entre versiones, que suelen ser lo que más pesa.
¿Hay módulos OCA para la contabilidad y facturación españolas?
Sí. El repositorio `l10n-spain` incluye módulos `l10n_es_` para modelos fiscales, SII, Facturae y remesas SEPA. Comprueba que el módulo concreto existe y está activo en tu versión de Odoo antes de usarlo en cierres fiscales.
¿Qué pasa con los módulos OCA al actualizar de versión de Odoo?
Cada módulo debe estar migrado a la rama de la nueva versión. Si no lo está, tendrás que esperar, migrarlo o prescindir de él. Revisa las ramas y los pull requests de migración antes de fijar la fecha de actualización.
