Most Powerful Open Source ERP

Business Templates Configuration Guidelines

rules to follow when creating new business templates.
  • Last Update:2016-04-08
  • Version:001
  • Language:en

The purpose of this document is to define the rules each developper has to follow when configuring ERP5 Business Templates. Following those rules will tremendously ease the integration of different Business Templates into a single ERP5 site. It will also prevent from inconsistencies between different modules inside an ERP5 site.

Table of Contents

You may also find some more information related to configuration of Forms and User Interface in UserInterfaceGuidelines.

Configuration Rules

Follow naming conventions

All ERP5 developers must follow the ERP5 naming convention : GuidelinesForNamingConvention

Use British English

Use appropriate titles in "british english" everywhere so that localisation becomes easy. Titles of fields, workflow states titles, transitions titles should be choosen carefully and must make sense from a business point of view. ERP5 vocabulary should be banished from user interface. Example 1 : "Shipping date" is preferred to "Start date" on a packing list. Example 2 : "Supplier" is preferred to "Source section" on a purchase order.

Use proxyfields of proxyfields everywhere.

Each Business Template should provide libraries of fields that will be used to define the forms associated to modules and documents. Those fields must be proxyfields of fields defined in ERP5 Base and defining the rendering. Fields in ERP5 Base BT library define the "rendering". Proxyfields in other BT library define the "logic" (example : definition of possible Portal Types in the "my_source_section" relation string field). See also Discussion/GuidelinesForFieldLibrary.

Relation string fields don't define relations with categories objects

Relation string fields should never permit to define relations with categories objects. Category should not be present in the Portal Type field of a relation string field (example : my_source, my_destination, my_resource field)

Portal Type Validation Workflows

Every portal type used as first level document in a module should be associated to a validation workflow.

Validation Workflows must define "Delete" state

All validation workflows must define "Deleted" state and "delete" transition. Security should be configured so that only managers can view documents in "Deleted" state. That means, for a common end user, deletion of documents in ERP5 should be seen as "physical" deletion.

Use getTranslatedLogicalPathItemList

The method used to display categories in list or multilist fields must be : getTranslatedLogicalPathItemList with sort by title. Obsolete, this is now a preference. Category Listfield must be proxyfields of Base_viewFieldLibrary/my_category, and adapt the TALES for special cases (eg. my_default_address_region wants to show the content of region category, but field ID is not my_region).

Provide i10 Sub Category

Standard business templates must provide "l10n" sub category as a single customisation place for localisation business templates. If every localisation business template obviously have to add some sub categories under a specific category, generic erp5 business template must provide "l10n" sub category first. And then each localisation business template add a country code name under the l10n sub category and use the below freely. For example, erp5_payroll uses base_amount category. Then erp5_payroll provides "base_amount/payroll/l10n" for localisation business templates. erp5_payroll_l10n_fr uses "base_amount/payroll/l10n/fr" and erp5_payroll_l10n_jp uses "base_amount/payroll/l10n/jp".

Related Articles