Multi-company configuration with OpenERP 6

IV Jornadas OpenERPLugo - Cámara de Comercio 05-26-2011 Multi-company configuration with 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

SummaryIntroductionConfiguration initial stepsActual situationVersion 6 featuresMulti-company oriented modulesImprovement proposalsCurrently confirmed bugsDoubts and questions

Introduction (I)A critical point in the maintenance and operational of companiesthat have implemented a 5-or earlier- version of OpenERP is theeffective management of a multi-company environment, becausein many situations it prevents them from working with the levelsof 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...

Introduction (and II)Thus, one of the 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...

Configuration initial steps (I)Create needed companies and establish their hierarchy from menuAdministration->Companies.Run wizard New Company Financial Setting under Accounting →Configuration → Financial Accounting menu for each company todefine their accounting trees, fiscal years and periods.Install the module nan_account_invoice_sequence (available onLaunchpad branch lp: openobject-addons/extra-6.0 extra-addons)and set up accounts for each company financial journals, properlydefining their daily unique sequences (eg SALES/2011/011 ) and theirshared sequences numbers (1, 2, 3, etc.). Also set the analytical journals associated with previous financial ones...

Configuration initial steps (II)For each module we install, we must add the group to the adminuser (at least) to make sure that the module functionality isavailable 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>

Configuration initial steps (III)Add the group Useability /Multi Companies to userswho need to work with morethan one company, so theycan switch between themeasily from their Preferences.

Configuration initial steps (and IV)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 theirTimesheet 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).

Actual situation: Groups (I) The key to success in shaping a multi-companyenvironment depends on how accurate we are creatingand combining the record rules and groups. However, although the group system allows greatflexibility, many of them are still too vertical (orhorizontal) for many business areas, which is a problemthat is emphasized in a multi-company environment.Eg Useability / Extended View group adds access on "Administration" and "Sales" menus.

Actual situation: Groups (II)Another problem 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 its 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>

Actual situation: Groups (III)That is, up to 3 different groups within thesame page; this means that if assigned to auser can give him more permits than needed ...This, of course, makes sense in the variousstate transitions involving an object (eg aninvoice), but perhaps not in the visible part ofthe information that is supposed to be availableto a project manager (group Project /Manager ).

Actual situation: Groups (and IV)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.

Actual situation: Record rulesThe record 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...

Actual situation: Visibility (I)Another problem for multi-company users is that many views(especially the list type ones) dont show the company_idfield 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).

Actual situation: Visibility (II) Two equal taxes? how strange...

Actual situation: Visibility (and III) Ah! Here is associated company... But I needed 2 clicks to see it! mmm...

Version 6 features (I)Useability / Multi Companies group its 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 ...

Version 6 features (II)Some relational fields "many to one" (many2one) have been transformed into properties in order to make its value dependant on users 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

Version 6 features (and III) 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()

Multi-company oriented modules (I): IntroductionThere are a number of modules developed by OpenERP SA, SYLEAM, Axelor, Nan.tic, Zikzakmediaand Pexego (among others) that improve in some way or another the behavior of certain objectsin 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.comHowever, most of them have become obsolete because they incorporate functionality that isalready widespread in native modules for version 6.Now, we will see a few categorized by functional area...

Multi-company oriented modules (II): Partners 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:

Multi-company oriented modules (III): Partners management (II)Module multi_company_sharebzr branch lp:openobject-addons/extra-6.0Developed 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 wont be associated with any.

Multi-company oriented modules (IV): Partners management (III)Module multi_partner_accountsAlready developed and put into production, but not yet released.Developed by por Pexego Sistemas Informáticos.Depends on: accountAdds 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 dont 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.

Multi-company oriented modules (V): Partners 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).

Multi-company oriented modules (VI): Accounting 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.

Multi-company oriented modules (VII): Accounting 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)

Multi-company oriented modules (VIII): Accounting Management (and III)There are more modules as multi_company_account, multi_currencyor currency_update_rate exploiting the possibilities of multi-currencyversions, 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.

Multi-company oriented modules (IX): Products managementModule 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.

Multi-company oriented modules (X): Human Resources ManagementModule 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.

Multi-company oriented modules (and XI): Rest of areas and Spanish Localization ModulesThe 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.

Improvement proposals (I)Refactoring group-based permissions: Either 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).

Improvement proposals (II)orm class in the core of OpenERP framework doesnt 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.

Improvement proposals (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)) (...)

Improvement proposals (and IV)Make official a multi-departmental management for all objects related to thedepartments: 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: class res_users(osv.osv): _inherit = res.users _columns = { context_department_id: fields.many2one(hr.department, Departments, context={user_preference: True}), } res_users()A better solution might be to create a record rule so that past performance is extendedto all objects (this has been introduced in multi_departments module).

Currently confirmed bugs (I)https://bugs.launchpad.net/openobject-client-web/+bug/780587Reported by Juanjo A. on 05/10/2011States that -using web client- when changing users 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/772419Reported by Christophe Chauvet on 04/28/2011States 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/772367Reported by Eric Caudal on 04/28/2011States that purchase reports printed by users belonging to a leaf company dont print companys logo because RML engine tries to obtain parent company logo. Ex: It can be checked with default company hierarchy "OpenERP SA→ Shop1”.

Currently confirmed bugs (II)https://bugs.launchpad.net/openobject-server/+bug/768175Reported 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/766573Reported by Ana Juaristi on 04/19/2011Exposes 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/741518Reported by Eric Caudal on 03/24/2011States that apart from filtering down company properties present in company or product objects (such asaccounts, 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.

Currently confirmed bugs (and III)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..) dont 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

Doubts and questions

EndThank you for your attention! alberto@pexego.esinfo@pexego.es / openerp@pexego.es http://www.pexego.es @albertoluengo / @pexego

Multi-company configuration with OpenERP 6

by Pexego on Jun 07, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 3

Statistics

Multi-company configuration with OpenERP 6 — Presentation Transcript

http://us-w1.rockmelt.com	1
http://paper.li	1
http://twitter.com	1