This section introduces ERP5 as part of Nexedi's stack of open-source software solutions followed by an overview of key technological components inherent in ERP5. To start developing ERP5 directly, please go to the getting started as a developer section. Feel free to ask any questions in our forum or get in touch with us directly through the contact section.

Open Source Stack

Wendelin Core

NEO

ERP5

SlapOS

Nexedi's software stack is completely open source and written in 100% Python. Besides the listed solutions a number of additional software products exists handling everything from networking to online/offline document management and application building. For a complete list of available software solutions, please refer to the free software section on the Nexedi website.

ERP5 Technical Introduction

The complexity of an ERP

ERP systems are quite complicated - they have to visualize and implement as much business logic of a company as possible. ERP5 distinguishes itself from other ERP systems (open and closed source) through its coherency down to the lowest - theoretical - level. It is based on a well developed theoretical model called the Unified Business Model.

Unified Business Model - Only Five Theoretical Classes

ERP5 defines an abstract model of business management called the Unified Business Model. Thanks to this clean abstraction layer new or custom business modules can always be implemented in a consistent way. This abstract business model can both be used to represent internal management activities as well as commercial and management activities across a group of companies.

The ERP5 abstract model is based on 5 classes:

• Resource:
  A resource describes a resource in a business process (e.g. the skill of a person, a currency, a raw material, a product). Relations between nodes allow to define BOM (Base Object Model) as well as prototypes.
• Node:
  A node is a place which can receive amounts of resources and send amounts of resources. Nodes can relate to physical entities (e.g. a workshop which receives raw materials, processes them and sends them away) or abstract entities (e.g. a bank account which can receive money). Stocks are a kind of Node. Metanodes are nodes which contain other nodes. A company is a metanode. A project is both a resource and a node.
• Movements:
  A movement describes the movement of an amount of a resource between two nodes at a given time and for a given duration. For example, a movement may send raw materials from a stock to a workshop, another movement may send money from one account to another.
• Path:
  A path allows to define a way for a node to access a resource it may eventually need. Prices and commercial profiles may be attached to a path in order to define the default price for a given resource procured at a given maker. Path may also define the way a workshop gets its resource from a stock. Paths have a start date and an end date. Paths may be used to represent the assignment of an individual to a temporary project.
• Item:
  An item describes a physical instance of a resource. A movement can be expanded into a series of trackable movements through items. Items also allow to define how a given amount of resources was actually shipped (e.g. parcels, serial numbers of items in each container, etc.)

Abstract Classes Mean Business

Five classes are sufficient to represent any business ranging from chemical plants and manufacturing to trading or services and can model all processes within an organisation, such as:

• A sale is a movement of a quantity of a product (resource) from a company (node) to the buyer (node) at a given price (path).
• An accounting entry is a movement of some money (resource) between two accounts (nodes).
• A phone call is a movement of an employee's time (resource) between the two parties.
• A training is a movement of a skill (resource) from nowhere (surprise!) to the trainee.

It sounds very abstract, but that's exactly why it is so powerful...

Modelling reality like this, we use the same attributes to describe very different things: every movement has its source and destination, plus some variations (e.g. in sales transactions the source is a physical location from which goods are shipped, while source_section is the owner who is selling the goods). And we can use standard, optimised API to calculate the results.

The key question is always: How much do we have of (this or that)? In our model a node doesn't really have "content"; when we want to know how much goods are in a warehouse, or what is the amount on an account, or how much time our support representative spent answering phone calls, we sum up quantities of all movements incoming to and outgoing from the node. To do so, we use a standard "getInventory" method which serves every purpose of this kind.

The ERP5 Simulation Model

Introducing Simulations

Simulations are one of the most powerful features of ERP5, although they are entirely hidden from the user. The idea is that movements which are supposed to have an impact on the future - or, in other words, which are going to cause some other movements - are equipped with so-called "rules" which are used to generate "simulation movements", which in turn can have their own rules and generate further simulation movements, thus "simulating" the future of our business. When the future becomes present and it's time to create real movements, we use simulation movements to check what, how much, for whom etc.

It is best explained on an example: if we accept a sales order, we know we'll sooner or later have to ship; and once we ship, we'd like to invoice; and once we invoice, we are going to get money. So a sale order is broken into lines, each line representing delivery of one product, and each line generates a simulation movement representing a shipment. Shipment then generates simulated invoice line, etc.

Simulating The Future

The benefits of this model are two-fold:

• Once we accepted an order, we can get a financial forecast straight from the system
• When we start packing, we can aggregate orders in any way we like - we don't have to pack order by order, instead we can generate a separate packing list for each product line, or combine all orders from the same customer into one big list, or even do both - create a separate packing list for products from the same product line ordered by the same customer over the last month, for instance. The point is to equip our ERP5 with appropriwately configured "builders" which will do the job.

Affiliation between MySQL and ZODB (ZEO or NEO)

In ERP5 all objects are put into ZODB (Zope Object Database) and they are indexed in SQL database (run on MariaDB RDBMS). This setup results in fast object searching and access, and on other hand - very easy object manipulation.

CMFActivity System - Background Process Invocation

ERP system logic may seem be very complicated, because any scripts can be attached to any object in the system. The advantage of this approach is that the consultant or application manager might want to have the ability to set up some scripts one by one, or to choose some special conditions which will happen before invoking some actions to prevent server resources to become overloaded.

ERP5 provides a built-in background process invocation system called CMFActivity. With this all resource-consuming tasks can be prioritised and put into the background. They will be invoked in whatever desired order, one at a time, such that resources of the machine won't be overconsumed. After invoking such tasks an icon appears on the user interfaces for all related objects indicating to the user that this object is waiting to be processed by a pending activity.

On a properly configured system CMFActivity may send messages about failed tasks. Developers and consultants are able to attach a special console - from Zope, and even from a system shell - to observe, cancel or force invocation of activities.

In a technical sense every task put into activity is a row in the SQL table. with a description for each object on what activity shall be run, what that activity is along with other properties. CMFActivity supports clustering and load-balancing of task queues.

In depth background process invocation and management is described on the ERP5 HowToUseTheCmfActivityTool.

Categories

Introduction to ERP5 Categories

The ERP5 system is based on categories. They are used to define the categorization and descriptive relation between objects in the system.

Categories are accessible and configurable through the Zope interface at:

[your_site]/portal_categories

(user "zope" can access if from the "My favourites" dropdown menu in the top left corner)

You will see a long list of "Base Categories". Click on any of them, you'll see they will have plenty of fields which you don't need to know anything about at this stage. Under the Action dropdown menu, you can find an option to create sub-categories, which can include sub-sub-categories and so on.

Some base categories (region, site, group, function, skill...) are used for categorization allowing you to build your trees within them; others (source, destination, subordination...) are used for setting relations between objects, and they don't need any subcategories.

The system accesses categories using special accessors, which makes categories translatable.

How are Categories Used in ERP5?

By defining a tree in a given base category a consultant is able to set up categorization with required depth. Examples of categorization categories are:

• region - to tell where a Person lives or where the Organisation has its headquarters
• skill - to tell who can do what
• quantity_unit - for definitions of quantity units for resources
• delivery_mode - describes modes of transport for orders
• gap - used for General Accounting Plan

The beauty of this category mechanism in ERP5 is that you can assign an object to one or more categories at your discretion, and that the notion of "category membership" goes all the way up the base category tree (meaning that if an object belongs to category "a/b/c", it belongs to category "a/b" and "a" too. That way, you can set up a category tree:

skill/dance
skill/dance/latino
skill/dance/latino/samba
skill/dance/latino/salsa
skill/dance/latino/rumba
skill/dance/classic
skill/dance/classic/waltz
skill/dance/classic/tango
skill/dance/ballet
skill/coding/c

Then assign persons to categories:

Joan
skill/dance/latino/samba
skill/dance/classic/tango
Mary
skill/dance/latino
Paul
skill/dance/ballet
Peter
skill/coding/c

Now, if you ask the system who can dance samba - you get Joan, Latino - you get Mary and Joan, classic/tango - Joan, classic - Joan, too; ask who can dance anything - you get Mary, Joan and Paul; and if you want to know who can't dance at all, you can get it too. All by using auto-generated accessor methods, without any fuss.

To see it in action, go to the "Persons" module and turn on the "domain tree" mode of the module's listbox; select "skill" from the dropdown, and you can browse your dancing resources.

Relation usage

As opposed to categorization usage some categories are used for relation system. Lets say, that we have Organisation object ACME and Sale Order object SO-1. We can define a relation between SO-1 and ACME using a source category. The sale system is implemented in such a way that the source category means that goods will be send from ACME.

Most popular relation categories are:

source
source_section
destination
destination_section
parent

Workflows

Introduction to Workflows

• States and Transitions:
  When an object is managed by a workflow, it means that it is subject to a procedure which this workflow represents. A procedure consists of some states and transitions between the states, and can be nicely represented by a graph, where boxes represent states, and arrows represent transitions. The workflow has an initial state, which the object assumes when it is created. If a transition is made, it changes its state to a destination state of the transition. Then another transition can be made, and so on until the object reaches a state from which there is no more transitions.
• Security:
  An important thing a workflow does is managing access rights to an object. For example, an article which is in a "draft" state should be accessible only to its author (for read and write), while "published" article should be readable by everyone and writable by nobody. Access rights can be defined and set separately for every workflow state.
• Conditions:
  A transition can be made available only to users who have certain rights in the system - for example, you have to be a "chief editor" to be allowed to publish an article. If you are not, you won't see the "Publish" action in your action box. A transition can also depend or other object properties - an article can be submitted for publication only if it contains some text, or an accounting entry can be confirmed only if credit and debit are equal.
• Side Effects:
  Workflow transitions can have "side effects" - actions to be executed when a transition is being made. Sticking to our publication workflow, when a document is being published, the system can send email notification to all subscribers. A more business-oriented example is that when a sale order is confirmed, the system generates a planned invoice.
• Interaction workflows:
  This is a different kind of a workflow - it has no states, and no transitions. Instead, it has "interactions", which are triggered when a given action is being made on an object. Interaction workflows are basically a cleaner and more portable way of implementing side effects - if we want a notification send when a document is published, we can do it by tweaking publication workflow, but we can instead add an interaction workflow with a "send notifications" interaction hooked to the "publish" action of the publication workflow.
• Edit Workflow:
  This is a special workflow, which is hooked to almost every object in ERP5. It is quite unusual because it has only one state - "current" - and one transition which goes back to the same state. This transition is executed every time an object is edited; the sole purpose of this workflow is recording the object's history.

Introduction to security

5A Security Model

ERP5 provides a simple and consistent view of business security by the 5A model. 5A consists of five generic roles: Author, Auditor, Assignor, Assignee and Associate. Users are associated with these roles on a per-module basis by local roles in each module. Local roles are roles which are effective only in a specific module or document, so it is possible to use a limited number of generic roles to decrease the complexity of the security problem.

The following roles can be assigned to a user:

• Author
  Author is the one who can create new documents. But the Author is not allowed to view documents. Suppose sales people who should register drafts of new sale invoice transactions. Usually these people may not do anything else, so they are authors.
• Auditor
  The Auditor is allowed to view documents but not allowed to create or modify documents. Suppose sales people who should know all products in your company but not concerned with any new product design. In this case, they are auditors but not authors.
• Assignor
  Assignor is the most responsible role. This role is allowed to do all tasks, and may assign other users as assignees of documents. This is used for sale manager, accounting manager, and so on.
• Assignee The Assignee is the one who can do all tasks under the control of Assignor. Assignee is used only if Assignor assigns a user as assignee of a document. Assignee is supposed to work on a part of a module. For example, you can define a worker as Assignee only for documents related to a specific customer, if the worker is familiar with the customer.
• Associate The Associate is allowed to do some tasks in a certain document only when another document related to that document is assigned. This is a bit complex, so consider this situation: You are a new worker in a very strict company. You are dealing with a sale order so you need to know the customer. Because this company does not want you to look at other customers, the manager of this company must limit your access to information on customers with which you must work. In other words, you are allowed to access a given customer only if a sale order assigned to you is related to the customer. This is the Associate.

In addition, ERP5 uses the role Owner which is a standard role in Zope. Owner is automatically assigned to a user, when the user makes a new document. So if you are willing to allow an author to view documents owned by the author, you can specify proper permission settings based on Owner.

More info on security can be found in Introduction to the ERP5 5A Security Model

Getting Started

With this overview you should be familiar with the core concepts behind ERP5. Head over to Getting Started as a developer to have a first try with ERP5.