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.
One should create a new portal type whenever:
One should not create a new portal type whenever:
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.
Consequences¶ in generic ERP5:
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
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.
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.
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: