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

Table of Contents

• Case 1: generic ERP5 bt5 - the goal is to minimize / unify / make generic
• Case 2: customised ERP5 in a client project - the goal is to make client users happy
• Consequences
• Limit Cases
  • About Orders, PL and Invoices: is 1b or 1A+1C the priority?
  • About Events: is 1b or 1C the priority?
  • About Contact inforations (ex. email, telephone, fax, URL, etc.), 1a+1b or 1C the priority?
  • About Documents (ex. Text, Spreadsheet): 1b or 1C ?
• Conclusion
• Related Articles

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¶

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

Conclusion¶

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¶

• Guidelines | A Document Form Uses The form_view Page Template
• Guidelines | A Fast Input Must Use object_fast_input Action
• Guidelines | A Validation Workflow Must Have A Delete State And Action
• Guidelines | Add Column Portal Type If Listbox Contains Multiple Types
• Guidelines | Add Date In Listbox As Editable Date-Time Field
• Guidelines | Add Viewable Listbox Fields To More Columns
• Guidelines | Always Provide Portal Type Description
• Guidelines | Configuration And Project Business Templates Must Include Roles For Group, Site And Function
• Guidelines | Define Declare Fast Input As Hidden Content Type
• Guidelines | Define Action Name Explicitly For Users
• Guidelines | Define And Translate Workflow Titles
• Guidelines | Define Count Method As countFolder On Module Listbox
• Guidelines | Define Document Actions As Global Actions
• Guidelines | Define Module Author And Auditor In Roles Tab Based On Use Cases
• Guidelines | Define Module Default Actions On Portal Action Tool
• Guidelines | Define Report Actions As object_report Linked With View Permission
• Guidelines | Define The Roles Allowed To Excecute A Transition
• Guidelines | Define Transition Title From A Business Point Of View
• Guidelines | Define Workflow Permission To Allow Redefinition On Workflow States
• Guidelines | Define Workflow Titles From A Business Point Of View
• Guidelines | Do Not Mix Description And Comment
• Guidelines | Do Not Test Required In Field View Form
• Guidelines | Favor simulation_state Or validation_state For Workflow State
• Guidelines | First Level Portal Types Should Have A Validation Workflow
• Guidelines | Forms Must Use Left, Right, Center, Bottom And Hidden Groups
• Guidelines | Generic Business Templates Must Have Security Roles Set On States And Transitions
• Guidelines | Hide Listbox Editable Fields On The Form
• Guidelines | Include Module Base Categories In Business Template
• Guidelines | Include Module Local Roles In Business Template
• Guidelines | Inside The Roles Tab, Assignor, Assignee, Associate And Auditor Must Be Defined
• Guidelines | ListField Or MultListField For Categories Must Use Item List Method
• Guidelines | Listbox Must Only Be Put In Form Bottom Group
• Guidelines | Listbox Only Tabs Should Have A Read Only Title In Center Group
• Guidelines | Listbox Selection Name Must Follow module_name_selection Pattern
• Guidelines | Never Allow Relation String Fields To Set Relations To Categories
• Guidelines | Never Set Search Row And Select Column On Listbox Inside Document View
• Guidelines | Never Show Or Make User Work With Document Id
• Guidelines | Never Use Multiple Modules For Person Or Organisation
• Guidelines | Place Simulation And Validation Fields At Bottom Of Right Group
• Guidelines | Set At Least View Action On Module Action Tab
• Guidelines | Set Content Permission To Fast Input
• Guidelines | Set Description On Form Fields
• Guidelines | Set Document Form Ids To PortalType_view
• Guidelines | Set Document Form Titles To What Is Displayed
• Guidelines | Set Form Action Base_doSelect On Forms
• Guidelines | Set Form Action To Base_edit
• Guidelines | Set Form Encytype to multipart/form-data When Using File Upload
• Guidelines | Set Form Id To ModulePortalType_viewPortalTypeList
• Guidelines | Set Form Title To What Is Displayed
• Guidelines | Set List Method To contentValues On Document Form Listbox
• Guidelines | Set Listbox Action To List Action On Document Form Listboxes
• Guidelines | Set Listbox Selection Name To form_name_selection_name
• Guidelines | Set Listbox Title To Plural Of Portal Type Title If Applicable
• Guidelines | Set Post Method And Utf-8 Encoding On Document Forms
• Guidelines | Set Priorities On Important Activities
• Guidelines | Split Large Forms On Multiple Tabs
• Guidelines | The Default Dialog Should Be Used For All Transitions
• Guidelines | The Listbox Method Should Be Defined As SearchFolder To View Modules
• Guidelines | Unset Acquire Local Roles On Document Portal Type Configuration If Applicable
• Guidelines | Use Activities For Heavy Computations
• Guidelines | Use Correct Names For Simulation And Validation Titles
• Guidelines | Use form_list Page Template On Forms
• Guidelines | Use getTranslatedId To Display Document Ids In Listbox Or Form
• Guidelines | Use Method Post And UTF-8 Encoding On Forms
• Guidelines | Use Proxy Fields Of Proxy Fields In Form
• Guidelines | Use Translated Portal Type To Display Portal Type
• Guidelines | Workflow Validation Scripts Must Be Well Defined
• Guidelines | Workflow Validation Scripts Must Return Translated Messages
• Guidelines | Workflows Should Define Worklists
• HowTo | Create New Modules
• Technical Note | Create Portal Type