Hola a todos!
Lanzo a continuación una duda que me ha surgido con un cliente que estaba en V15CE y se le ha migrado a V17CE.
Este cliente trabajaba en V15 con el concepto de empresas "grupo". Para ello, en el maestro de compañías, estableció las relaciones jerárquicas entre ellas. A pesar de ello, en V15 cada compañía tenía su plan de cuentas y sus impuestos. Todo Ok hasta ahí. En V15, el concepto de "grupo" no va mucho más allá de un campo poco más que informativo.
Con la actualización a V17CE vía Open Upgrade, sin incidencias reseñables y puesta en producción recientemente, hemos visto que se están produciendo una serie de efectos "colaterales" pues por lo que se ve, el concepto de "grupos de empresas" en V17 es un cambio estructural de mayor calado del que pueda parecer.
El cliente continúa teniendo en V17 para cada compañía (incluso si forman parte de un grupo) su propio conjunto de impuestos y cuentas contables, como consecuencia del proceso de migración, que es correcto que se haya realizado así, y entiendo que los scripts de OpenUpgrade no manifiesten ningún tipo de error o advertencia (que yo me haya dado cuenta), pues los datos coexisten sin conflictos.
El problema ha venido cuando el cliente ha comenzado sus procesos de contabilización habituales, os cuento algunos ejemplos para agregar contexto.
Cuando en V17 el cliente selecciona cualquier empresa que forme parte del grupo, en numerosos lugares en los que se deben seleccionar cuentas contables, impuestos, diarios bancarios, ahora Odoo muestra los de todas las empresas del grupo (independientemente de que en el selector de compañías esté seleccionada una sola o todas las compañías pertenecientes al grupo).
Por ejemplo:
-En V17, ahora por ORM se han impuesto constrains que impiden que se creen cuentas contables con mismo código para empresas que forman parte del grupo. Por ejemplo, si tenemos una empresa "A" (padre) y una empresa "B" (dependiente de "A"), puedo crear una única cuenta 629001, que se creará de forma predeterminada para la compañía "A". Pero si queremos agregar otra 629001 para la compañía "B", Odoo lanzará un error por el constrains ("Los códigos de cuenta son únicos para un grupo de empresas"). La cuenta se deberá compartir entre ambas compañías de forma obligada.
-Como el cliente viene de V15, en donde se tenía un plan de cuentas para cada compañía, sus datos se migraron del mismo modo a V17. Por lo tanto, ahora si el cliente quiere crear una factura de cliente o proveedor, al escribir la cuenta contable, ejemplo 629001, le saldrán en el selector de campo dos cuentas 629001 (o tantas como dependencias jerárquicas existan en el grupo), sin que el usuario sepa qué cuenta debe escoger (solo sale el código y descripción de la cuenta).
-En los paneles contables, ahora se muestran todos los diarios de todas las empresas que forman parte del grupo, independientemente de que en el selector de compañías se haya escogido solo la matriz o alguna subsidiaria. Estos dominios "parent_of" están extensamente replicados a nivel contable en todo Odoo.
-Cuando un usuario está en una empresa "B" que es subsidiaria (dependiente) de la compañía "A", cuando se hace clic en "Registrar pago" a una factura, se mostrarán como seleccionables todos los diarios de todas las compañías del grupo.
-A pesar de que, como consecuencia de la migración actualmente el usuario tiene su plan contable independiente, cualquier cuenta que quiera dar de alta en adelante, deberá compartir código entre todas las empresas del grupo (por la restricción comentada anteriormente).
En fin, hay numerosos ejemplos más. El caso es que Odoo parece haber decidido que desde V17, los planes de cuentas y los maestros de impuestos deben ser comunes para todas las compañías pertenecientes a un grupo, y esto se aleja enormemente de la realidad jurídica y operativa de España, en donde la noción de grupo empresarial a efectos fiscales es independiente de la consolidación contable que, por lo que se ve, Odoo obliga a realizar desde V17.
Y no hablemos de grupos empresariales heterogéneos en los que posiblemente tenga menor sentido planteamientos de reestructuración del plan de cuentas para que estén alineados unas compañías con otras.
¿Alguien en un caso parecido con migraciones pendientes o realizadas a V17 de clientes que son grupos de empresas? Querría compartir opiniones o criterios que estáis aplicando.
Gracias,
Ignacio
Hola Ignacio,
Muy buen punto el que planteas. Es un tema complejo y de gran relevancia que nos hemos encontrado también, y tu análisis de los efectos "colaterales" de la migración a v17 es muy acertado.
El Diagnóstico: El Cambio de Paradigma en v17
Efectivamente, el concepto de "grupo de empresas" (parent_id) en Odoo 17 ha dejado de ser meramente informativo para convertirse en un pilar estructural, especialmente en el ámbito contable. Odoo ahora asume que las empresas de un mismo grupo deben compartir recursos clave como el plan contable y los impuestos, lo que choca frontalmente con la realidad jurídica y operativa en España, donde las empresas de un grupo suelen ser entidades fiscales independientes.
El resultado, como bien dices, es que la experiencia de usuario se resiente, y el tablero de contabilidad puede volverse un "callejero de Nueva York", mostrando diarios, cuentas e impuestos de todas las empresas del grupo y generando confusión.
Estrategias y Soluciones en Community Edition
Ante este escenario, hemos explorado principalmente dos vías, dependiendo de la estructura real del cliente.
Opción 1: Eliminar la Jerarquía y Usar Informes Consolidados Externos (MIS Builder)
Esta es la solución más directa y limpia si las empresas del grupo son fiscalmente independientes.
Esquema de partida:
GRUPO (Entidad virtual para reporting)
Empresa 1 (Independiente fiscalmente)
Empresa 2 (Independiente fiscalmente)
Etc.
Acción: Tratar a todas las empresas (1, 2, 3, 4) como entidades independientes en Odoo, eliminando cualquier parent_id que las vincule. La empresa "GRUPO" puede seguir existiendo, pero sin relaciones jerárquicas.
Consolidación: Para obtener los informes agregados que antes se buscaban con la estructura de grupo, la mejor alternativa en Community es, sin duda, el módulo MIS Builder de la OCA. Permite crear informes financieros y analíticos totalmente personalizables que pueden consolidar datos de múltiples compañías sin problema. La configuración inicial requiere un mapeo de cuentas, pero una vez hecho, es una herramienta potentísima.
Nuestra estrategia de migración: En nuestro caso, para las migraciones, optamos por eliminar el parent_id de las empresas hijas antes de migrar con OpenUpgrade. Es una solución directa que evita desde el origen los constraints y dominios parent_of que describes.
Opción 2: Replicar una Lógica de Consolidación (Aproximación a Enterprise)
El problema de la primera opción es cuando el cliente sí desea una consolidación "no fiscal" operativa dentro de la empresa GRUPO.
Referencia: Odoo Enterprise cuenta con el módulo account_consolidation, que está diseñado precisamente para gestionar estos escenarios, tanto fiscales como no fiscales.
Solución en Community: Si el cliente necesita esta funcionalidad, y dado que en España los planes contables suelen ser homogéneos, es factible desarrollar un módulo a medida que replique la lógica básica de consolidación. Esto permite mantener la independencia operativa de cada empresa mientras se agregan los datos en la compañía "GRUPO" para su análisis.
El desafío se multiplica, como apuntas, cuando los planes contables son heterogéneos o entran en juego distintas divisas. En esos casos, la complejidad del desarrollo a medida aumenta considerablemente.
Conclusión
En resumen, la decisión de Odoo de endurecer la lógica de los grupos de empresas en v17 nos obliga a replantear la arquitectura multi-compañía. Para la mayoría de los casos en España, la Opción 1 (eliminar jerarquías y usar MIS Builder) es la más pragmática y limpia.
Da para escribir un libro, ya que cada cliente y su estructura empresarial es un mundo.
Me sumo totalmente a la idea de organizar una mesa redonda para compartir experiencias. Sería muy enriquecedor para todos.
Un saludo,