Configuración multi-compañia con OpenERP 6

IV Jornadas
OpenERP

Lugo - Cámara de
Comercio

26-05-2011

Configuración multi-compañía con
OpenERP 6

Alberto Luengo Cabanillas
alberto@pexego.es

S o lu c io n e s a v a n z a d a s p a r a In t e r n e t

Índice General
Introducción
Pasos iniciales de configuración
Problemática actual
Novedades en la versión 6
Módulos multi-compañía
Propuestas de mejora
Bugs confirmados actualmente
Dudas y preguntas

Introducción (I)

Un punto crítico en el mantenimiento y operativa de las empresas
que tienen implantada una versión 5 -o anterior- de OpenERP es
la gestión eficaz de un entorno multi-compañía, ya que en
muchos escenarios les impide trabajar con los niveles de
visibilidad que desean o necesitan.
...aparte de que la adaptación de módulos para que soportasen un
entorno multi-compañía (campo 'company_id', reglas de registro, etc.)
se convertía en una tarea costosa de implementar y mantener...

Introducción (y II)
Así, uno de los aspectos fundamentales del paso
de versiones anteriores a la versión 6 de
OpenERP ha sido la gestión nativa de un entorno
multi-compañía con la extensión de
prácticamente todos los objetos que introducen
los distintos módulos.
Además también se ha convertido en un buen
argumento comercial de cara a los posibles
clientes...

Pasos iniciales de
configuración (I)
Crear las compañías que vayamos a necesitar y determinar su jerarquía desde
el menú 'Administración->Compañías'.

Ejecutar el asistente de 'Configuración financiera de nueva compañía' bajo el
menú 'Contabilidad → Configuración → Contabilidad Financiera' para cada
compañía con el fin de definir sus árboles contables, años fiscales y períodos.

Instalar el módulo 'nan_account_invoice_sequence' (disponible en la rama de
Launchpad lp:openobject-addons/extra-6.0 extra-addons) y configurar los
diarios contables para cada compañía, definiendo correctamente sus secuencias
de diario únicas (por ejemplo VENTAS/2011/011) y sus secuencias de asientos
compartida (1, 2, 3, etc.).
Asimismo configurar los diarios analíticos asociados a los anteriores diarios contables...

Pasos iniciales de
configuración (II)
Por cada módulo que instalemos, tenemos que asegurarnos de
añadir los grupos correspondientes que cargue dicho módulo al
usuario administrador (por lo menos).
Esto se debe a que muchos de ellos ahora incorporan la siguiente
instrucción: context={'noadmin':True}
P.ej. Módulo 'account', fichero 'account_security.xml':

<record id="group_account_user" model="res.groups"
context="{'noadmin':True}">
<field name="name">Accounting / Accountant</field>
</record>

Pasos iniciales de
configuración (III)
Añadir el grupo 'Useability /
Multi Companies' a los
usuarios que necesiten
trabajar con más de una
compañía, para que puedan
cambiar entre ellas de forma
sencilla desde sus
Preferencias.

Pasos iniciales de
configuración (y IV)
Determinar la jerarquía de departamentos de las compañías.
Definir la relación 'usuario<->empleado'.
La relación 'compañía<->empresa' ya se define automáticamente al
crear la primera.
Configurar los productos hora de cada uno de los empleados
dentro de la pestaña 'Horarios' de su ficha.
Nos ahorrará problemas futuros (por ejemplo, en el momento que un
miembro de un proyecto quiera imputar sus horas).
¡No utilizar el usuario Administrador más que lo
necesario! (ya que no le afectan las reglas de multi-
compañía).

Problemática actual: Grupos (I)
La clave del éxito en la configuración de un entorno multi-
compañía dependerá de lo precisos que seamos creando y
combinando las reglas de registro y grupos.

Sin embargo, aunque el sistema de grupos permite una gran
flexibilidad, muchos de ellos siguen siendo demasiado verticales (o
transversales) para muchas áreas de negocio, lo cual es un
problema que en un entorno multi-compañía se acentúa.
P.ej. El caso del grupo 'Useability/Extended View' que añade acceso
sobre menús de “Administración” y “Ventas”.

Problemática actual: Grupos
(II)
Otro problema que nos encontramos es que muchos filtros
grupales se encuentran todavía hardcodeados en las vistas, lo
cual dificulta en gran medida una gestión de permisos eficiente.
P.ej. Un caso problemático es la pestaña de la información contable
de los proyectos en la que tenemos definido lo siguiente:

<page string="Billing" groups="account.group_account_invoice">
    <field colspan="4" name="partner_id"
on_change="onchange_partner_id(partner_id)" select="1" string="Customer"/>

    <field domain="[('partner_id','=',partner_id)]" name="contact_id"
string="Invoice Address"/>
    <field name="warn_customer"/>
    <field name="currency_id" select="1" groups="base.group_multi_company"
required="1"/>
     <newline/>
     (...)
    <group col="3" colspan="4" groups="base.group_extended">
      (...)
    </group>
</page>

Problemática actual: Grupos
(III)
Es decir, hasta 3 grupos distintos dentro de una
misma página, los cuales asignados a un
usuario puede habilitarle más permisos de los
necesarios...
Esto desde luego tiene lógica en las distintas
transiciones de estado por las que puede pasar
un objeto (por ejemplo, una factura), pero
quizás no en la visibilidad de parte de la
información que se supone corresponde a un
jefe de Proyecto (grupo 'Project /Manager').

Problemática actual: Grupos (y
IV)
Otro problema a mayores de esta verticalidad de grupos es la
imposibilidad de realizar acciones o finalizar flujos de trabajo que a
priori no parecen relacionados.

Un caso de uso puede ser el de la creación de productos. Si un usuario por
ejemplo es jefe de almacén (grupo 'Warehouse/Manager') y da de alta un
producto no va a tener problema; sin embargo necesitará pertenecer al
grupo 'Accounting/Manager' (o que otro empleado de este grupo) para
completarlo y poderlo vender, cobrar, facturar, etc.

Otro caso es el jefe de ventas (grupo 'Sales/Manager') que quiere emitir
una factura a partir de su pedido confirmado y necesita pertenecer a los
grupos 'Accounting/Invoice', 'Warehouse/User' o 'Sales/User'.

Problemática actual: Reglas de
registro
Las reglas de registro han mejorado con respecto a las
versiones anteriores, permitiendo filtros de aplicación a
nivel de grupo u operación CRUD.
Se ha eliminado el modelo 'ir.rule.group' en favor de la
bidireccionalidad entre grupos y reglas.
Soportan agrupación y permiten establecer dominios
basados en campos relacionales, jerarquías, etc.
Por tanto, y debido a sus características, constituyen una
herramienta muy útil en la gestión de entornos multi-
compañía.
Sin embargo, la notación prefija que utilizan no sea la más
apropiada o intuitiva para el usuario...

Problemática actual:
Visibilidad (I)
Otro problema para los usuarios multi-compañía es que en muchas
vistas (sobre todo las de tipo lista) falta el campo 'company_id' lo cual
dificulta la gestión de objetos.

Esto es especialmente preocupante en la parte de contabilidad ya que, por
ejemplo, si un usuario que puede trabajar con varias compañías quiere
revisar el listado de IVAs tiene que entrar en cada uno de ellos para saber a
qué compañía están asociados, al igual que con los periodos, diarios, etc.

Se dio también en su momento en el listado de productos (véase
https://bugs.launchpad.net/openobject-addons/+bug/764855).

Visibilidad (II)

¿Dos IVAs al 18%?
qué extraño...

Visibilidad (y III)

¡Ah! Aquí está...
Pero ya he tenido que hacer ¡2 clicks!
ufff....

Novedades en la versión 6 (I)

Se ha introducido el grupo 'Useability/Multi Companies'
creado específicamente para que un usuario pueda gestionar un
entorno multi-compañía.
Proporciona acceso a distintos menús de configuración filtrados por la
compañía activa en la que trabaja el usuario.
Por lo tanto es indispensable para los usuarios que trabajen con varias
compañías (caso típico de departamento de contabilidad), aunque su
asignación debe realizarse con precaución y siempre acompañada por
las reglas de registro y los controles de acceso pertinentes...

Novedades en la versión 6 (II)

Algunos campos relacionales “muchos a uno” (many2one) se
han transformado en propiedades para poder hacer su valor
variable en función de la compañía del usuario.
Aunque la mayoría ya han venido heredadas de la versión 5
(contabilidad, stock, etc.) hay módulos como
'product_multi_company' (presente en los addons) que
sustituyen ciertos campos por propiedades.
Ej.: property_reserve_and_surplus_account → relativa a la cuenta de
pérdidas y ganancias de las compañías

Novedades en la versión 6 (y
III)
Se ha introducido el parámetro 'user_preference' en el contexto que
limita de forma sencilla el acceso a un objeto relacionado en función
de la compañía a la que pertenezca actualmente el usuario.
Por ejemplo, podríamos sobreescribir el campo 'context_department_id'
y tener filtrados los posibles departamentos a los que puede
pertenecer un usuario, mostrando únicamente los que están asociados
a su compañía activa:
class res_users(osv.osv):
_inherit = 'res.users'
_columns = {
'context_department_id': fields.many2one('hr.department',
'Departments', context={'user_preference': True}),
}
res_users()

Módulos multi-compañía (I):
Introducción
Existe una serie de módulos desarrollados por OpenERP S.A., SYLEAM, Axelor, Zikzakmedia y
Pexego (entre otros) que mejoran de alguna u otra manera el comportamiento de ciertos objetos
en un entorno multi-compañía.
Dichos módulos están repartidos entre varias ramas:
lp:openobject-addons/extra-6.0 (multi_company, multi_company_account, multi_company_currency,
multi_company_hr_timesheet_sheet, multi_company_price, multi_company_product,
multi_company_project, multi_company_sequence, multi_company_share, multi_company_stock,
nan_account_extension, product_multi_company...)
lp:~pexego/openobject-addons/extra-6.0 (multi_departments)
...o se pueden descargar directamente desde http://apps.openerp.com

Sin embargo, la mayor parte de ellos han quedado obsoletos debido a que la funcionalidad que
incorporan ya viene extendida de forma nativa en los módulos correspondientes de la versión 6.

A continuación veremos unos cuantos categorizados por áreas funcionales.

Módulos multi-compañía (II):
Gestión de partners (I)
En un entorno con varias compañías puede ser
interesante compartir partners o direcciones entre
ellas sin tener que duplicarlos constantemente.

Sin embargo, tenemos la problemática de que las
properties contables sí o sí van a tener que asociarse
a una compañía. Para solventar (o agilizar) este
problema tenemos los siguientes módulos:

Módulos multi-compañía (III):
Gestión de partners (II)
Módulo multi_company_share
bzr branch lp:openobject-addons/extra-6.0
Desarrollado por ZikZakMedia SL.
Dependencias: 'product'.
Extiende las compañías con dos checkbox de tal forma que -si
están marcados- los partners, direcciones y productos que cree
un usuario de dicha compañía no estarán asociados a ninguna.

Módulos multi-compañía (IV):
Gestión de partners (III)
Módulo multi_partner_accounts

Ya desarrollado y puesto en producción, pero todavía no liberado.
Desarrollado por Pexego Sistemas Informáticos, S.L.
Dependencias: 'account'
Añade un asistente para configurar las cuentas debe y haber por defecto de los partners
para cada compañía (4300000 y 4100000, por ejemplo) y extiende la compañía con esas
dos cuentas para que puedan ser configuradas a posteriori.
Crea automáticamente la cuenta 430000x y/o 410000x que le corresponda a cada partner
en el árbol contable de su compañía, con la particularidad de que se propagarán por el
resto del árbol de compañías si es que a dicho partner no se le asocia ninguna compañía.
Para ello, también añade dos secuencias específicas para clientes y proveedores.
El objetivo es tener un único partner disponible para todas las compañías y tener varias
cuentas contables del mismo repartidas entre los árboles de todas ellas.

Módulos multi-compañía (V):
Gestión de partners (y IV)
Módulo nan_account_extension

Desarrollado por Nan-Tic
Entre sus otras funcionalidades (principalmente centradas en la
gestión contable y la facturación), incluye la creación, borrado
y actualización automática de las cuentas contables de un
partner (configurable por compañía).

Módulos multi-compañía (VI):
Gestión contable (I)
Módulo nan_account_invoice_sequence

Desarrollado por Nan-Tic
Separa las secuencias de los diarios contables de la secuencia única de
numeración que deben seguir los movimientos contables
La diferencia con el módulo 'account_sequence' radica en que en vez de
crear un nuevo número interno en los movimientos (lo cual requeriría
cambiar un montón de informes), simplemente convierte el campo
relacionado “número de factura” en un campo carácter normal.

Módulos multi-compañía (VII):
Gestión contable (II)
Módulo analytic_multicurrency

Desarrollado por CamptoCamp
Dependencias: 'account', 'analytic', 'account_analytic_analysis'
Permite compartir cuentas analíticas entre compañías (incluso si tienen
divisas distintas)
El propietario de la linea de la cuenta analítica pasa a ser la compañía a la
que pertenece su cuenta contable asociada
Añade multi-divisa a las lineas analíticas (de forma similar a la contabilidad
financiera)

Módulos multi-compañía (VIII):
Gestión contable (y III)

Existen más módulos como multi_company_account, multi_currency,
currency_update_rate que explotaban las posibilidades de la
multidivisa en versiones anteriores, pero que, en el caso de los dos
primeros, han quedado obsoletos...
Nota: El módulo 'currency_update_rate' desarrollado por CamptoCamp sí ha
sido migrado a la versión 6 y actualiza las tasas de conversión entre divisas
mediante un cron conectándose a varias APIs públicas de Internet.
Asimismo, soporta multi-compañía.

Módulos multi-compañía (IX):
Gestión de productos
Módulo product_multi_company

Desarrollado por OpenERP SA
Dependencias: 'product'
Sustituye los campos de precio al público, precio estándar y precio de
venta de los productos por propiedades dependientes de las
compañías.

Módulos multi-compañía (X):
Gestión Recursos Humanos
Módulo multi_departments

bzr branch lp:~pexego/openobject-addons/extra-6.0
Desarrollado por Pexego Sistemas Informáticos, S.L.
Dependencias: 'hr'
Añade un campo many2many de departamentos a los usuarios
Añade los campos 'código' y 'usuarios' a los departamentos para
mantener la bidireccionalidad
Añade una regla de registro para limitar los departamentos del usuario
en función de su compañía

Módulos multi-compañía (y XI):
Resto de áreas y módulos de la
comunidad española
El resto de áreas funcionales “principales” (compras, ventas,
proyectos, producción y logística) ya traen soporte nativo para
multi-compañía en sus módulos principales ('delivery', 'stock',
'sale', etc.).

Por otro lado, prácticamente todos (si no todos) los módulos de la
comunidad española (l10n_es_*) han sido adaptados para
soportar la gestión multi-compañía.

Propuestas de mejora (I)
Refactorización del sistema de permisos basado en grupos:
Bien mediante la implementación de un nivel superior de jerarquía que agrupase
a los distintos grupos para facilitar su gestión...
Esto permitiría cambios de permisos en bloque basados en los perfiles funcionales que
manejase la empresa
...o bien mediante la creación de grupos a más bajo nivel para evitar la
transversalidad de los mismos.

Otra posible solución temporal es la duplicación de grupos, eliminando el acceso
a los distintos menús que les proporciona el grupo original pero manteniendo los
permisos sobre los objetos (o viceversa).
Esto puede resultar útil sobre todo en los grupos de Contabilidad (por ejemplo,
podríamos tener un grupo 'Accounting/Invoice' y un 'Accounting/Invoice No
Menus').

Propuestas de mejora (II)
En la clase orm del núcleo del framework de OpenERP
no se tiene en cuenta en ninguna operación CRUD la
compañía...
Esto revierte en un incremento del tiempo de ejecución de
ciertas ejecuciones.
Un caso de uso que se ha analizado es la creación en cascada de
cuentas contables para un partner sobre 9 árboles contables de 9
compañías distintas, la cual, con la siguiente modificación, hemos
conseguido reducir de 9-11 míns. aprox. a 2-3 míns.

Propuestas de mejora (III)
class orm(orm_template):
@@ 3635,8 +3637,12 @@
(...)
+  company_id = context.get('company_id') and context['company_id'].id or vals.get('company_id') and
vals['company_id']
(...)
  cr.execute('select parent_right from '+self._table+' where '+self._parent_name+'=%s order by '+
(self._parent_order or self._order), (parent,))
+  if company_id:
+      cr.execute('select parent_right from '+self._table+' where '+self._parent_name+'=%s and
company_id='+str(company_id)+' order by '+(self._parent_order or self._order), (parent,))
+  else:
+     cr.execute('select parent_right from '+self._table+' where '+self._parent_name+'=%s order by '+
(self._parent_order or self._order), (parent,))
(...)
  cr.execute('select parent_left from '+self._table+' where id=%s', (parent,))
+  if company_id:
+     cr.execute('select parent_left from '+self._table+' where id=%s and company_id='+str(company_id),
(parent,))
+  else:
+     cr.execute('select parent_left from '+self._table+' where id=%s', (parent,))
(...)
  cr.execute('update '+self._table+' set parent_left=parent_left+2 where parent_left>%s', (pleft,))
  cr.execute('update '+self._table+' set parent_right=parent_right+2 where parent_right>%s', (pleft,))
  cr.execute('update '+self._table+' set parent_left=%s,parent_right=%s where id=%s', (pleft+1, pleft+2,
id_new))
+  if company_id:
+     cr.execute('update '+self._table+' set parent_left=parent_left+2 where parent_left>%s and
company_id='+str(company_id), (pleft,))
+     cr.execute('update '+self._table+' set parent_right=parent_right+2 where parent_right>%s and
company_id='+str(company_id), (pleft,))
+     cr.execute('update '+self._table+' set parent_left=%s,parent_right=%s where id=%s and
company_id='+str(company_id), (pleft+1, pleft+2, id_new))
+  else:
+     cr.execute('update '+self._table+' set parent_left=parent_left+2 where parent_left>%s', (pleft,))
+     cr.execute('update '+self._table+' set parent_right=parent_right+2 where parent_right>%s', (pleft,))
+     cr.execute('update '+self._table+' set parent_left=%s,parent_right=%s where id=%s', (pleft+1, pleft+2,
id_new))
(...)

Propuestas de mejora (y IV)
Hacer “oficial” la gestión multidepartamental para todos los objetos relacionados con los
departamentos: proyectos, usuarios, etc.
Como ya hemos visto, por ejemplo -y haciendo referencia a los usuarios- podríamos sobreescribir su
campo 'context_department_id' y tener filtrados los posibles departamentos a los que puede
pertenecer un usuario, mostrando únicamente los que están asociados a su compañía activa:

class res_users(osv.osv):
_inherit = 'res.users'
_columns = {
'context_department_id': fields.many2one('hr.department', 'Departments',
context={'user_preference': True}),
}
res_users()

Una mejor solución podría ser la de crear una regla de registro de tal forma que el
comportamiento anterior se extendiese a todos los objetos (introducido en el módulo
multi_departments).

Bugs confirmados
actualmente (I)
https://bugs.launchpad.net/openobject-client-web/+bug/780587
Reportado por Juanjo A. el 10/05/2011
Expone que en el cliente web el cambio de compañía del usuario desde su menú de Preferencias no
se realiza 'al vuelo' y queda enganchado a la sesión (cosa que no ocurre en el cliente GTK).

https://bugs.launchpad.net/openobject-server/6.0/+bug/772419
Reportado por Christophe Chauvet el 28/04/2011
Expone que ciertos campos propiedad del partner no tienen en cuenta la compañía cuando son leídos.
Este bug aunque actualmente se encuentra confirmado, en realidad parece que ha quedado obsoleto, ya que
las pruebas hechas con dos usuarios (no admin) sobre el campo 'posición fiscal' de un mismo partner han
arrojado resultados satisfactorios...

https://bugs.launchpad.net/openobject-server/+bug/772367
Reportado por Eric Caudal el 28/04/2011
Expone que en los informes de compra de los usuarios asociados a una compañía “hija” no se imprime el logo
de dicha compañía porque el motor RML intenta acceder al logo de la compañía “padre”.
Ej: Se puede comprobar con la jerarquía de compañías por defecto “OpenERP SA → Shop1”.

Bugs confirmados
actualmente (II)
Reportado por Ferdinand el 21/04/2011
Expone una posible violación de la integridad de datos utilizando el cliente web si un mismo usuario inicia varias
sesiones simultáneas sobre la misma BD, poniendo como ejemplo el caso de que un usuario quiera registrar una
llamada de una iniciativa que tenga abierta de la compañía B mientras está trabajando con la compañía A.
Propone que la compañía quede enganchada a un identificador de sesión y un usuario en vez de como se maneja
actualmente: enganchada al usuario.
Ha sido catalogado dentro de la 'Wishlist'.

https://bugs.launchpad.net/openerp-spain/+bug/766573
Reportado por Ana Juaristi el 19/04/2011
Expone que se ejecuta un número innecesario de veces los asistentes de configuración contable general y el propio de
la localización española en el escenario en el que tengamos varias compañías con planes contables distintos.

https://bugs.launchpad.net/openobject-addons/+bug/741518
Reportado por Eric Caudal el 24/03/2011
Expone que aparte del filtrado por compañía que establecen las propiedades presentes en los objetos 'Empresa' o
'Producto' (como cuentas contables, posiciones fiscales, etc) se deberían establecer filtros en función de la compañía
asociada al producto.
Ej: Si un usuario tiene acceso a las compañías A y B y tiene definido un producto de la compañía B, el usuario sólo
debería poder ver y asociar la cuenta 700xxxx del árbol de la compañía B.

Bugs confirmados
actualmente (y III)
https://bugs.launchpad.net/openobject-addons/+bug/735766
Reportado por mvhman el 15/03/2011
Expone que ciertos campos de las categorías de los productos, aún siendo
propiedades (cuenta de ingresos, cuenta de gastos, etc.) no tienen reglas multi-
compañía como las plantillas de productos.

Reportado por Ferdinand el 07/02/2011
Expone que: suponiendo que tenemos un entorno multi-compañía del estilo
“OpenERP SA {padre de} Shop1”, cuando un usuario (por ejemplo, el administrador)
perteneciente a la compañía OpenERP SA crea un nuevo usuario, la compañía que se
le asigna por defecto a este nuevo usuario es OpenERP SA. Si ahora le intentamos
asignar la compañía “Shop1” y guardar, saltará el siguiente error:
Ha ocurrido un error mientras se validaban los campo(s)
company_id,company_ids: La compañía seleccionada no está en las compañías
permitidas para este usuario

Fin

¡Gracias por su atención!

alberto@pexego.es
info@pexego.es
http://www.pexego.es
@albertoluengo / @pexego

Configuración multi-compañia con OpenERP 6

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Configuración multi-compañia con OpenERP 6

Similaire à Configuración multi-compañia con OpenERP 6 (20)

Plus de Pexego

Plus de Pexego (6)

Dernier

Dernier (20)

Configuración multi-compañia con OpenERP 6