Configuración multi-compañia con OpenERP 6

IV Jornadas OpenERPLugo - 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 GeneralIntroducciónPasos iniciales de configuraciónProblemática actualNovedades en la versión 6Módulos multi-compañíaPropuestas de mejoraBugs confirmados actualmenteDudas y preguntas

Introducción (I)Un punto crítico en el mantenimiento y operativa de las empresasque tienen implantada una versión 5 -o anterior- de OpenERP esla gestión eficaz de un entorno multi-compañía, ya que enmuchos escenarios les impide trabajar con los niveles devisibilidad 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 desdeel menú Administración->Compañías.Ejecutar el asistente de Configuración financiera de nueva compañía bajo elmenú Contabilidad → Configuración → Contabilidad Financiera para cadacompañí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 deLaunchpad lp:openobject-addons/extra-6.0 extra-addons) y configurar losdiarios contables para cada compañía, definiendo correctamente sus secuenciasde diario únicas (por ejemplo VENTAS/2011/011) y sus secuencias de asientoscompartida (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 deañadir los grupos correspondientes que cargue dicho módulo alusuario 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 losusuarios que necesitentrabajar con más de unacompañía, para que puedancambiar entre ellas de formasencilla desde susPreferencias.

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 empleadosdentro 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 lonecesario! (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 unamisma página, los cuales asignados a unusuario puede habilitarle más permisos de losnecesarios...Esto desde luego tiene lógica en las distintastransiciones de estado por las que puede pasarun objeto (por ejemplo, una factura), peroquizás no en la visibilidad de parte de lainformación que se supone corresponde a unjefe 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 registroLas 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 muchasvistas (sobre todo las de tipo lista) falta el campo company_id lo cualdificulta 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).

Problemática actual: Visibilidad (II) ¿Dos IVAs al 18%? qué extraño...

Problemática actual: 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ónExiste una serie de módulos desarrollados por OpenERP S.A., SYLEAM, Axelor, Zikzakmedia yPexego (entre otros) que mejoran de alguna u otra manera el comportamiento de ciertos objetosen 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.comSin embargo, la mayor parte de ellos han quedado obsoletos debido a que la funcionalidad queincorporan 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 bzr branch lp:openobject-addons/extra-6.0 Desarrollado por Nan-Tic Dependencias: account 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 bzr branch lp:openobject-addons/extra-6.0 Desarrollado por Nan-Tic Dependencias: account 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 bzr branch lp:openobject-addons/extra-6.0 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 lamultidivisa en versiones anteriores, pero que, en el caso de los dosprimeros, 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 productosMódulo product_multi_company bzr branch lp:openobject-addons/extra-6.0 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 HumanosMó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ñolaEl 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 losdepartamentos: 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 elcomportamiento anterior se extendiese a todos los objetos (introducido en el módulomulti_departments).

Bugs confirmados actualmente (I)https://bugs.launchpad.net/openobject-client-web/+bug/780587Reportado por Juanjo A. el 10/05/2011Expone 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/772419Reportado por Christophe Chauvet el 28/04/2011Expone 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/772367Reportado por Eric Caudal el 28/04/2011Expone 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)https://bugs.launchpad.net/openobject-server/+bug/768175Reportado 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/766573Reportado por Ana Juaristi el 19/04/2011Expone 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/741518Reportado por Eric Caudal el 24/03/2011Expone que aparte del filtrado por compañía que establecen las propiedades presentes en los objetos Empresa oProducto (como cuentas contables, posiciones fiscales, etc) se deberían establecer filtros en función de la compañíaasociada 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/735766Reportado por mvhman el 15/03/2011Expone que ciertos campos de las categorías de los productos, aún siendopropiedades (cuenta de ingresos, cuenta de gastos, etc.) no tienen reglas multi-compañía como las plantillas de productos.https://bugs.launchpad.net/openobject-server/+bug/714471Reportado por Ferdinand el 07/02/2011Expone 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 sele asigna por defecto a este nuevo usuario es OpenERP SA. Si ahora le intentamosasignar 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

Dudas y preguntas

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

by Pexego on Jun 01, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 5

Statistics

Configuración multi-compañia con OpenERP 6 — Presentation Transcript

http://paper.li	3
http://twitter.com	1
http://a0.twimg.com	1