Multi-company configuration with OpenERP 6

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

IV Jornadas IV Jornadas OpenERP OpenERP

Lugo - Cámara de Lugo - Cámara de ComercioComercio

05-26-201105-26-2011

Multi-company configuration with OpenERP 6

Alberto Luengo [email protected]

SummarySummary

Introduction

Configuration initial steps

Actual situation

Version 6 features

Multi-company oriented modules

Improvement proposals

Currently confirmed bugs

Doubts and questions

Introduction (I)Introduction (I)

A critical point in the maintenance 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...

Introduction (and II)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...

SummarySummary

Introduction


Actual situation

Version 6 features





Configuration initial steps (I)Configuration initial steps (I)Create needed 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...

Configuration initial steps (II)Configuration initial steps (II)For each 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>

Configuration initial steps (III)Configuration initial steps (III)Add the 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.

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

SummarySummary

Introduction


Actual situation

Version 6 features





Actual situation: Groups (I)Actual situation: Groups (I)

The key 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.

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

Actual situation: Groups (III)Actual situation: Groups (III)

That is, 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 ').

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

The 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)Actual situation: Visibility (I) Another problem 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).

Actual situation: Visibility (II)Actual situation: Visibility (II)

Two equal taxes?how strange...

Actual situation: Visibility (and Actual situation: Visibility (and III)III)

Ah! Here is associated company...But I needed 2 clicks to see it!

mmm...

SummarySummary

Introduction


Actual situation

Version 6 features





Version 6 features (I)Version 6 features (I)

'Useability / 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 ...

Version 6 features (II)Version 6 features (II)

Some relational 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

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

SummarySummary

Introduction


Actual situation

Version 6 features





Multi-company oriented Multi-company oriented modules (I): Introductionmodules (I): Introduction

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...

Multi-company oriented Multi-company oriented modules (II): Partners modules (II): Partners

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:

Multi-company oriented Multi-company oriented modules (III): Partners modules (III): Partners

management (II)management (II)Module multi_company_sharebzr 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.

Multi-company oriented Multi-company oriented modules (IV): Partners modules (IV): Partners

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.

Multi-company oriented Multi-company oriented modules (V): Partners modules (V): Partners management ( and IV)management ( and IV)

Module nan_account_extension

bzr branch lp:openobject-addons/extra-6.0

Developed by por Nan.tic


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

Management (I)Management (I) Module nan_account_invoice_sequence


Developed by Nan.tic


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

Management (II)Management (II) Module analytic_multicurrency


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

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.

Multi-company oriented Multi-company oriented modules (IX): Products modules (IX): Products

managementmanagement Module product_multi_company


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

Resources ManagementResources 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.

Multi-company oriented modules Multi-company oriented modules (and XI): Rest of areas and (and XI): Rest of areas and

Spanish Localization ModulesSpanish 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.

SummarySummary

Introduction


Actual situation

Version 6 features





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

'orm' class in the 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.

Improvement proposals (III)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 Improvement proposals (and IV)IV)

Make official 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()

SummarySummary

Introduction


Actual situation

Version 6 features





Currently confirmed bugs (I)Currently confirmed bugs (I)

https://bugs.launchpad.net/openobject-client-web/+bug/780587

Reported 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/772419Reported 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/772367Reported 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”.→

https://bugs.launchpad.net/openobject-client-web/+bug/780587

https://bugs.launchpad.net/openobject-server/6.0/+bug/772419

https://bugs.launchpad.net/openobject-server/+bug/772367

Currently confirmed bugs (II)Currently confirmed bugs (II) https://bugs.launchpad.net/openobject-server/+bug/768175

Reported by Ferdinand on 04/21/2011Exposes 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 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/openerp-spain/+bug/766573

https://bugs.launchpad.net/openobject-addons/+bug/741518

Currently confirmed bugs (and Currently confirmed bugs (and III)III)

https://bugs.launchpad.net/openobject-addons/+bug/735766Reported by mvhman on 03/15/2011States 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/714471Reported by Ferdinand on 02/07/2011States 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

https://bugs.launchpad.net/openobject-addons/+bug/735766


SummarySummary

Introduction


Actual situation

Version 6 features





Doubts and questionsDoubts and questions

EndEnd

Thank you for your attention!

[email protected]

[email protected] / [email protected]

http://www.pexego.es

@albertoluengo / @pexego

mailto:[email protected]

mailto:[email protected]

http://www.pexego.es/

Multi-company configuration with OpenERP 6

Technology

Transcript of Multi-company configuration with OpenERP 6