Most Powerful Open Source ERP

When Should One Create A New Portal Type

Here are presented the two cases when one should create a new portal type.
  • Last Update:2016-05-16
  • Version:001
  • Language:en

Here are presented the two cases when one should create a new portal type.

Table of Contents

When should one create a new portal type in ERP5. There are 2 cases: generic ERP5 business templates and client project.

Case 1: generic ERP5 bt5 - the goal is to minimize / unify / make generic

One should create a new portal type whenever:

  • 1a. the properties & categories are too different and can not be shared
  • 1b. the actions are too different and can not be merged
  • 1c. the workflows are different and can not be merged
  • 1d. the security is different and there is no way to merge it

One should not create a new portal type whenever:

  • 1A- it breaks a possible symmetry (client/supplier, product/component, tax/insurance)
  • 1B- an existing portal type can be used instead
  • 1C- the reason to create the portal type is only to differentiate among identical portal types of the same family

The notion of symmetry is important in ERP5 in case it is used by a group of companies, one being the supplier of the other. Breaking symmetry prevents unification of base data at the group level.

Case 2: customised ERP5 in a client project - the goal is to make client users happy

One should create a new portal type whenever:

  • 2a- portal_type represents and existing operational business document
  • 2b- it helps users adopting the application

One should not create a new portal type whenever:

  • 2A- it breaks an existing symmetry (client/supplier, product/component, tax/insurance)
  • 2B- two business documents with different name are actually the same
  • 2C- it makes the application harder to understand by users


Consequences in generic ERP5:

  • 1- Person / Organisation -> perfect (role category can be used to select the role)
  • 2- Product / Component -> Product only + resource_role
  • 3- Service / Tax / Discount / etc. -> Service only + resource_role

where resource_role describes all the possible roles or resources (ex. discount, tax, component, product, etc.)

Let us analyse the reasons for these changes:

1. is well known

2. the product of the supplier is a component for the client

3. the health tax of the client is the insurance service of the supplier. the gas surcharge is a tax for the client but a service for the vendor

Consequences in customised ERP5: None

Limit Cases

About Orders, PL and Invoices: is 1b or 1A+1C the priority?

  • 1- Sale Order / Purchase Order / Internal Order -> only Order ? + movement_role
  • 2- Sale PL / Purchase PL / Internal PL -> only PL ? + movement_role
  • 3- Sale Invoice Transaction / Purchase Invoice Transaction/ Internal Invoice Transaction -> only Invoice ? + movement_role
  • 4- Payment Transaction / Accounting Transaction -> Transaction + movement_role

where movement_role describes all the different kinds of journals (for accountants) or orders (for others).

A unificiation approach is not necessarily wrong. It solves the symmetry issue of the current approach (ie. only Internal Order / PL / Invoice are symmetric). It could actually be quite nice to provide extra flexibility (ex. many journals in accounting, different families or purchase orders, etc.). With a good templates which can provide good presets for movement roles, it can even be usable. However, it would require to generate different documents based on source/destination categories. For example, only Sale Invoices and Internet Invoice are actually printed by users. The layout of a Purchase Order and the juridical information it contains are often different from the layout of the Sale Order. Actions to place an order online or to receive an order are different. Therefore, if 1b is the priority (because we do not want to differentiate actions based on categories), then the current approach is fine. We could also invoke the fact that the possible symmetry invoked in 1a is already covered by Internal Orders.

About Events: is 1b or 1C the priority?

  • 1b -> processing an incoming fax and an incoming phone call is quite different in terms of possible actions (ex. TIF processing + OCR vs. voice recognition / TIF display vs. sound play). We are in the same situation as in DMS (Text / Spreadsheet / etc.)
  • 1C -> all events share the same ERP5 data structure

In the case of events, we have an additional issue: the resource does not represent the event technical nature (ex. Fax, Phone) but the Event busines nature (ex. public relations, etc.). The technical nature would have to be handled by a separate category.

About Contact inforations (ex. email, telephone, fax, URL, etc.), 1a+1b or 1C the priority?

  • 1a -> telephone and email use different properties
  • 1b -> calling someone, sending an email, a fax or accessing a generic URL uses a different action
  • 1C -> all contact informations could be considered as generic URLs with a generic URL handler

About Documents (ex. Text, Spreadsheet): 1b or 1C ?

  • 1b -> the actions on Text, Spreadsheet are potentially very different, mostly due to user interface (ERP5 Forms)
  • 1C -> all OOo Documents share the same data structure


Product and Component must be unified into Product.

Service, Tax, Surcharge, Commission and Discount must be unified into Service.

A new category, resource_role, must be used to differentiate the role of resources in ERP5.

Just like with role on Person & Organisation, resource_role may have an impact on security settings on larger sites (ie. the people who can define client contact information are not the same as those who can define supplier contact information).

If dynamic action selection based on a category is considered as acceptable, it is necessary to study the possible unification of:

  • all order, PL and Invoice types
  • all event types
  • all OOo document types

Related Articles