Multi-company configuration with OpenERP 6

IV Jornadas
OpenERP

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

Summary
Introduction
Configuration initial steps
Actual situation
Version 6 features
Multi-company oriented modules
Improvement proposals
Currently confirmed bugs
Doubts and questions

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

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

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

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)

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

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:

modules (III): Partners
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.

modules (IV): Partners
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.

modules (V): Partners
management ( and IV)
Module nan_account_extension

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

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

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

modules (VIII): Accounting
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.

modules (IX): Products
management
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.

modules (X): Human
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.

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

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 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)
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 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:

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 extended
to all objects (this has been introduced in 'multi_departments' module).

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

Currently confirmed bugs (II)
Reported 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.

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..) don't have multi-company rules as product
templates.

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

End

Thank you for your attention!

alberto@pexego.es
info@pexego.es / openerp@pexego.es
http://www.pexego.es
@albertoluengo / @pexego

Multi-company configuration with OpenERP 6

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Multi-company configuration with OpenERP 6

Similar to Multi-company configuration with OpenERP 6 (20)

More from Pexego

More from Pexego (6)

Recently uploaded

Recently uploaded (20)

Multi-company configuration with OpenERP 6