This presentation talks about all problems regarding with one of the greatest features in OpenERP 6: multi-company. Also, author proposes some improvements and comments some bugs found by OpenERP community during first six months of 2011
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 05-26-2011 05-26-2011 Multi-company configuration with OpenERP 6 Alberto Luengo Cabanillas [email protected]
and operational of companies that have implemented a 5-or earlier- version of OpenERP is the effective management of a multi-company environment, because in many situations it prevents them from working with the levels of visibility they want or need. ... besides, adaptation of modules for supporting a multi-company environment (field 'company_id' registration rules, etc.) became a costly task to implement and maintain for developers...
fundamental aspects for upgrading from versions prior to OpenERP version 6 has been the native management of a multi-company environment including the extent of almost all core objects that introduce the different modules. In addition it has also become a good business case for potential customers...
companies and establish their hierarchy from menu 'Administration->Companies'. Run wizard 'New Company Financial Setting' under 'Accounting → Configuration Financial Accounting → ' menu for each company to define their accounting trees, fiscal years and periods. Install the module 'nan_account_invoice_sequence' (available on Launchpad branch lp: openobject-addons/extra-6.0 extra-addons) and set up accounts for each company financial journals, properly defining their daily unique sequences (eg SALES/2011/011 ) and their shared sequences numbers (1, 2, 3, etc.). Also set the analytical journals associated with previous financial ones...
module we install, we must add the group to the admin user (at least) to make sure that the module functionality is available for him. This is because many of them now include following statement: context={'noadmin':True} For example: Module 'account', file 'account_security.xml': <record id="group_account_user" model="res.groups" context="{'noadmin':True}"> <field name="name">Accounting / Accountant</field> </record>
group 'Useability / Multi Companies' to users who need to work with more than one company, so they can switch between them easily from their Preferences.
Determine the hierarchy of departments in all companies. Define the relationship 'user <-> employee'. ...because now the relationship 'company <->partner' is automatically set when creating the company. Configure 'hour' products for each employee under their 'Timesheet' tab. This will save us future problems (for example, when a member of a project want to impute his hours). Do not use the Administrator user more than necessary! (as it will not be affected by multi-company rules).
to success in shaping a multi-company environment depends on how accurate we are creating and combining the record rules and groups. However, although the group system allows great flexibility, many of them are still too vertical (or horizontal) for many business areas, which is a problem that is emphasized in a multi-company environment. Eg 'Useability / Extended View' group adds access on "Administration" and "Sales" menus.
we found is that many filters are still hardcoded in XML files, which seriously hampers effective management of permissions. Eg A problematic case is the 'Accounting' tab in projects where it's defined the following: <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>
up to 3 different groups within the same page; this means that if assigned to a user can give him more permits than needed ... This, of course, makes sense in the various state transitions involving an object (eg an invoice), but perhaps not in the visible part of the information that is supposed to be available to a project manager (group 'Project / Manager ').
Another major problem of this horizontal way of defining groups is the inability to complete actions or workflows that a priori do not seem to be related. A use case can be the creation of products. If a user is a warehouse manager ('Warehouse / Manager' group) he will have no problem creating a product, but he will need to belong to the 'Accounting / Manager' group to complete its creation and be able to sell it, charge it, bill it, etc.. Another example is a sales manager ('Sales / Manager' group) that wants to issue an invoice after a confirmed order and needs to belong to 'Accounting / Invoice', 'Warehouse / User' or 'Sales / User' groups.
rules have been improved over previous versions, allowing to configure their access rights by CRUD operations or filtering their action by group. It has been removed 'ir.rule.group' model for mainteining bidirectionality between groups and rules. Support combination of rules and allow setting domains based on relational fields, hierarchies, etc. Therefore, and due to their characteristics, constitute a very useful tool in managing multi-company environments. However, using prefix notation is not the most appropriate and intuitive way of manage them for some users...
for multi-company users is that many views (especially the list type ones) don't show the 'company_id' field making it difficult for quick object management. This is of particular concern in the accounting, since, for example, if a user who can work with several companies want to review the taxes list, he will have to enter in each of them to know which company they are associated, as with periods, journals, etc. It also happened in products list (see https://bugs.launchpad.net/openobject-addons/ +bug/764855).
Multi Companies' group it's been created specifically for a user to manage a multi-company environment. Provides access to configuration menus filtered by current active company in which the user works. Therefore it is essential for users working with several companies (typical case of the accounting department), although its allocation should be done with caution and always accompanied by record rules and proper access controls ...
fields "many to one" (many2one) have been transformed into properties in order to make its value dependant on user's company. Although most have been inherited from the version 5 (accounting, stock, etc..) modules as 'product_multi_company' (found in addons) now replace certain fields for properties. Eg property_reserve_and_surplus_account field relative to the profit → and loss account of companies
It has been introduced the parameter 'user_preference' in the context, limiting access to a related object according to the company that the user currently belongs. For example, we could override the 'context_department_id' field in 'res.users' model and filter all possible departments that may belong to a user, displaying only those associated with his active company: class res_users(osv.osv): _inherit = 'res.users' _columns = { 'context_department_id': fields.many2one('hr.department', 'Departments', context={'user_preference': True}), } res_users()
There are a number of modules developed by OpenERP SA, SYLEAM, Axelor, Nan.tic, Zikzakmedia and Pexego (among others) that improve in some way or another the behavior of certain objects in a multi-company environment. These modules are divided among several branches: 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) ...or can be downloaded directly from http://apps.openerp.com However, most of them have become obsolete because they incorporate functionality that is already widespread in native modules for version 6. Now, we will see a few categorized by functional area...
management (I) management (I) In an environment with several companies may be interesting to share partners or addresses between them without having to duplicate consistently. However, we have the problem that the accounting properties have to be necessarily associated to a company. To solve (or minimize) this issue we have the following modules:
management (II) management (II) Module multi_company_share bzr branch lp:openobject-addons/extra-6.0 Developed by ZikZakMedia. Depends on: 'product'. Extends companies with two checkboxes so, if marked, the partners, addresses and products that create a user of that company won't be associated with any.
management (III) management (III) Module multi_partner_accounts Already developed and put into production, but not yet released. Developed by por Pexego Sistemas Informáticos. Depends on: 'account' Adds a wizard to configure the default partner credit and debit accounts for each company (4300000 and 4100000, in Spanish accounting for example) and adds these two accounts to the company, so they can be configured afterwards. Automatically creates the 430000x and / or 410000x account that correspond to each partner in the accounting tree of the company, with the particularity that it will be propagated to the rest of the companies tree if this partner don't belong to any company. For achieving this, the module also adds two specific sequences for customers and suppliers. The goal is to have a single partner available to all companies and his accounts distributed among all accounting companies tree.
management ( and IV) management ( and IV) Module nan_account_extension bzr branch lp:openobject-addons/extra-6.0 Developed by por Nan.tic Depends on: 'account' Among its other features (mainly focusing on account management and billing), includes the creation, deletion and automatic update of all accounts from a partner (configurable per company).
Management (I) Management (I) Module nan_account_invoice_sequence bzr branch lp:openobject-addons/extra-6.0 Developed by Nan.tic Depends on: 'account' Separates accounting journals sequences from the unique numbering sequence Spanish account moves must legally follow. The difference with the module 'account_sequence' is that rather than creating a new internal number of movements (which would require changing a lot of reports), simply turns the related field "invoice number" field in a normal character.
Management (II) Management (II) Module analytic_multicurrency bzr branch lp:openobject-addons/extra-6.0 Developed by CamptoCamp Depends on: 'account', 'analytic', 'account_analytic_analysis' Allows analytical account sharing between companies (even if they have different currencies). The owner of the analytical account line becomes the company that owns his associated financial account. Multi-currency added to the analytical lines (similar to financial accounts)
Management (and III) Management (and III) There are more modules as multi_company_account, multi_currency or currency_update_rate exploiting the possibilities of multi-currency versions, but in the case of the first two, are obsolete ... Note: The module 'currency_update_rate' developed by CamptoCamp it has been migrated to version 6 and updates the rates of currency conversion by connecting to several Internet public APIs. It also supports multi-company.
management management Module product_multi_company bzr branch lp:openobject-addons/extra-6.0 Developed by OpenERP SA Depends on: 'product' Replaces retail price, standard price and selling price fields in products to company dependent properties.
Resources Management Resources Management Module multi_departments bzr branch lp:~pexego/openobject-addons/extra-6.0 Developed by Pexego Sistemas Informáticos. Depends on: 'hr' Adds a many2many departments field to users. Adds 'code ' and 'users' fields to departments to maintain bidirectionality. Adds a record rule to limit the user departments based on their company.
areas and (and XI): Rest of areas and Spanish Localization Modules Spanish Localization Modules The other main functional areas (purchase, sale, projects, production and logistics) already bring native support for multi- company on their core modules ('delivery', 'stock', 'sale ', etc.). On the other hand, almost all (if not all) the modules of the Spanish community (l10n_es_*) have been designed to support multi-company management.
by implementing a higher level of hierarchy for grouping different groups for easier management ... This would permit batch changes based on functional profiles present in the company ... or by creating lower-level groups to prevent cross-cutting them. Another possible workaround is the duplication of groups, removing accesses to the menus provided by the original group but keeping the permissions on the objects (or vice versa). This can be particularly helpful in accounting groups (for example, we could have a group called 'Accounting / Invoice' and another called 'Accounting / Invoice No Menus').
core of OpenERP framework doesn't take the company into account in any CRUD operation... This implies an increase in the time of execution of certain operations. A use case that has been discussed is the cascade creation of partner accounts over 9 accounting trees belonging to 9 different companies, which, with the following modification in this class, we have reduced from 9-11 mins. approx. to 2-3 mins.
+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)) (...)
a multi-departmental management for all objects related to the departments: projects, users, etc. As we have seen, for example, we could override 'context_department_id' field in 'res.users' object and filter all possible departments that may belong to a user, displaying only those associated with his active company: A better solution might be to create a record rule so that past performance is extended to all objects (this has been introduced in 'multi_departments' module). class res_users(osv.osv): _inherit = 'res.users' _columns = { 'context_department_id': fields.many2one('hr.department', 'Departments', context={'user_preference': True}), } res_users()
by Juanjo A. on 05/10/2011 States that -using web client- when changing user's company from his Preferences menu this is not done on the fly and remains engaged in the session. https://bugs.launchpad.net/openobject-server/6.0/+bug/772419 Reported by Christophe Chauvet on 04/28/2011 States that certain partner property fields do not take company into account when they are read. This bug is now confirmed but actually seems to have become obsolete, since the tests made with two users (not admin) on the 'fiscal position' of one partner have yielded satisfactory results... https://bugs.launchpad.net/openobject-server/+bug/772367 Reported by Eric Caudal on 04/28/2011 States that purchase reports printed by users belonging to a 'leaf' company don't print company's logo because RML engine tries to obtain 'parent' company logo. Ex: It can be checked with default company hierarchy "OpenERP SA Shop1”. →
by Ferdinand on 04/21/2011 Exposes a possible violation of data integrity using the web client if one user starts multiple concurrent sessions on the same BD, citing the case that a user wants to record a call from an open initiative involving company 'B' while is working with the company 'A'. Proposes that the company is engaged in a session ID and a user rather than as currently managed, attached to the user. Has been listed within the 'Wishlist'. https://bugs.launchpad.net/openerp-spain/+bug/766573 Reported by Ana Juaristi on 04/19/2011 Exposes that general accounting setup and Spanish accounting setup wizards are running an unnecessary number of steps in case we have several companies with different accounting systems. https://bugs.launchpad.net/openobject-addons/+bug/741518 Reported by Eric Caudal on 03/24/2011 States that apart from filtering down company properties present in 'company' or 'product' objects (such as accounts, tax positions, etc) should be set filters according to the company associated with the product. Ex: If a user has access to companies A and B and has defined a product of company B, the user only should see the company B associated account tree.
https://bugs.launchpad.net/openobject-addons/+bug/735766 Reported by mvhman on 03/15/2011 States that certain fields of product categories, even being properties (revenue account, expense account, etc..) don't have multi-company rules as product templates. https://bugs.launchpad.net/openobject-server/+bug/714471 Reported by Ferdinand on 02/07/2011 States that: if we have a multi-company environment like 'OpenERP SA{father_of}Shop1', when a user (eg administrator) belonging to the company OpenERP SA creates a new user, the company that is assigned by default to this new user is OpenERP SA. If you now try to assign the company "Shop1” and save, the following error pops up: Error occurred while validating the field(s) company_id,company_ids: The chosen company is not in the allowed companies for this user
pexego
raccoon_hd_hr
designlabo
ar_tama
gakkenleap
electricsatie
campfire
findyinc
cuebicventures
macloud
kenjisugiura
yuka_kakiuchi
202200
keithpitt
62gerente
danielanewman
productmarketing
zakiyama
sstephenson
colly
chriscoyier
ammeep
notwaldorf
tammyeverts
![End End Thank you for your attention! [email protected] [email protected] /](https://files.speakerdeck.com/presentations/4e817b352ad818006000429a/slide_45.jpg){kind=link}