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

Esta presentación, expuesta en las Jornadas del 2011 de OpenERP en Lugo, abarca los distintos problemas relativos a una de las grandes mejoras que se introdujeron en la última versión del software de gestión OpenERP. Asimismo, propone una serie de mejoras y enumera los distintos "bugs" encontrados durante el primer semestre del 2011.

Transcript

1. 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 IV Jornadas IV Jornadas OpenERP OpenERP Lugo - Cámara de Lugo - Cámara de Comercio Comercio 26-05-2011 26-05-2011 Configuración multi-compañía con OpenERP 6 Alberto Luengo Cabanillas alberto@pexego.es
2. Índice General Í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
3. Introducción (I) 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...
4. Introducción (y II) 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...
5. Índice General Í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
6. Pasos iniciales de Pasos iniciales de configuración (I) 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...
7. Pasos iniciales de Pasos iniciales de configuración (II) 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>
8. Pasos iniciales de Pasos iniciales de configuración (III) 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.
9. Pasos iniciales de Pasos iniciales de configuración (y IV) 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).
10. Índice General Í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
11. Problemática actual: Grupos (I) 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”.
12. Problemática actual: Grupos Problemática actual: Grupos (II) (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>
13. Problemática actual: Grupos Problemática actual: Grupos (III) (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').
14. Problemática actual: Grupos (y Problemática actual: Grupos (y IV) 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'.
15. Problemática actual: Reglas de Problemática actual: Reglas de registro 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...
16. Problemática actual: Problemática actual: Visibilidad (I) 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).
17. Problemática actual: Problemática actual: Visibilidad (II) Visibilidad (II) ¿Dos IVAs al 18%? qué extraño...
18. Problemática actual: Problemática actual: Visibilidad (y III) Visibilidad (y III) ¡Ah! Aquí está... Pero ya he tenido que hacer ¡2 clicks! ufff....
19. Índice General Í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
20. Novedades en la versión 6 (I) 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...
21. Novedades en la versión 6 (II) 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
22. Novedades en la versión 6 (y Novedades en la versión 6 (y III) 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()
23. Índice General Í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
24. Módulos multi-compañía (I): Módulos multi-compañía (I): Introducción 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.
25. Módulos multi-compañía (II): Módulos multi-compañía (II): Gestión de partners (I) 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:
26. Módulos multi-compañía (III): Módulos multi-compañía (III): Gestión de partners (II) 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.
27. Módulos multi-compañía (IV): Módulos multi-compañía (IV): Gestión de partners (III) 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.
28. Módulos multi-compañía (V): Módulos multi-compañía (V): Gestión de partners (y IV) 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).
29. Módulos multi-compañía (VI): Módulos multi-compañía (VI): Gestión contable (I) 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.
30. Módulos multi-compañía (VII): Módulos multi-compañía (VII): Gestión contable (II) 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)
31. Módulos multi-compañía (VIII): Módulos multi-compañía (VIII): Gestión contable (y III) 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.
32. Módulos multi-compañía (IX): Módulos multi-compañía (IX): Gestión de productos Gestión de productos Mó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.
33. Módulos multi-compañía (X): Módulos multi-compañía (X): Gestión Recursos Humanos 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
34. Módulos multi-compañía (y XI): Módulos multi-compañía (y XI): Resto de áreas y módulos de la Resto de áreas y módulos de la comunidad española 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.
35. Índice General Í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
36. Propuestas de mejora (I) 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').
37. Propuestas de mejora (II) 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.
38. Propuestas de mejora (III) 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)) (...)
39. Propuestas de mejora (y IV) 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: 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). class res_users(osv.osv): _inherit = 'res.users' _columns = { 'context_department_id': fields.many2one('hr.department', 'Departments', context={'user_preference': True}), } res_users()
40. Índice General Í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
41. Bugs confirmados Bugs confirmados actualmente (I) 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”. →
42. Bugs confirmados Bugs confirmados actualmente (II) actualmente (II) https://bugs.launchpad.net/openobject-server/+bug/768175 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.
43. Bugs confirmados Bugs confirmados actualmente (y III) 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. https://bugs.launchpad.net/openobject-server/+bug/714471 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
44. Índice General Í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
45. Dudas y preguntas Dudas y preguntas
46. Fin Fin ¡Gracias por su atención! alberto@pexego.es info@pexego.es http://www.pexego.es @albertoluengo / @pexego