In an article published in 200X by IEEE review “IT Pro”, Smets & Carvalho introduced a new concept in Enteprise Modelling: the “Unified Business Model”. Departing from traditional field based modeling and culture dependent ontologies, ERP5 uses only 5 elementary concepts to represent any business process: Node, Resource, Movement, Item and Path. Some author call this meta-ontlogy. It means that in ERP5, accounting, production, trade, inventory, human resource all share the same model. Algorithms created for inventory management can thus be used for accounting or human resource management. This dramatically reduces the code base of ERP5 and makes it manageable by a small team of developers. Also, in ERP5 only 10 tables are necessary to run a full ERP whereas in most ERPs, thousands if not tens of thousands of tables are required. This makes reporting with ERP5 much easier to grasp at first glance. ERP5 introduced many other innovations in the field of ERPs. It is document based whereas most ERPs are base on a data model. ERP5 represents information as documents which are similar to those used in a company: purchase order, sales invoice, packing list, etc. Document orientation is now being copied by Agile developers for enteprise applications, but without the benefits of ERP5 “Unified Business Model”.

ERP5 was from the start web based on workflow based. Most other ERPs later copied this approach.

ERP5 an open source ERP born in a swimsuit factory in the north of France in 2001. It was designed to be generic and flexible enough to suit different business areas and maximise economies of scale related to code sharing. It was also designed to be used through the Web – rather through rich desktop clients which were still at that time the preferred approach – to match the requirements of globalization and the increasing distributed nature of modern small companies.

ERP5 is written in Python language and based Zope Object Database (ZODB). ERP5 is compatible with any operating system including GNU/Linux, MacOS, BSD and Windows. Still, Linux is the preferred operating system to run ERP5.

ERP5 supports most relational databases, including MySQL, PostgreSQL, Oracle, Ingres, Sphinx, etc. MySQL database is the favourite for fast transaction management.

ERP5 architecture is based on modules called “business templates”. Business templates leverage the ERP5 framework to provide generic functional features (ex. accounting), business field specific features (ex. banking) or customer specific features (ex. configuration of accounting for a company named Beteireflow). ERP5 architecture encapsulates within a single object oriented packaging format both source code, configuration data, base data, test data and test cases. Together with native version control system, ERP5 provides one of the easiest development environments for complex enterprise applications.

ERP5 uses NoSQL where most ERPs used to be based on SQL modeling. ERP5 uses application server level programming in python where most ERPs used to be based on database stored procedures. ERP5 uses state machine representation of workflows where most ERPs used to hardcode decision workflows.

ERP5 is still the only ERP based on a NoSQL approach. What has often been considered as an “exotic” choice by industry experts is now acknowledged to be the most scalable choice for web applications. Facebook, Google, Mixi, etc. all use a NoSQL approach to achieve highest scability. This is also how ERP5 was designed 10 years ago.

All data entered by the user is in ERP5 “stored as such” then transformed and indexed into any kind of index: SQL relational, RDF, full text, LDAP, etc. The underlying idea is to use the most efficient index for a given reporting or data mining purpose. It is also possible to combine multiple index engines. Some people call this approach the “search engine based” approach for enterprise applications.

ERP5 NoSQL and search-engine based architecture prevent bugs which happen at the input stage to generate inconsistent data without any possibility to later recover this inconsistency. This is a direct application of the defensive programming guidelines of ERP5: “write code so that it still works even if something does not work”. If a bug happens during the transformation phase before indexing, it is always possible to reindex data since user input was stored as such.

ERP5 was initially designed after CMF, Zope based content management framework. CMF was a source of inspiration for other content management framewors, including Zope Toolkit (ZTK). ERP5 departs from CMF original design in three ways: explicit forms, explicit data model and categories.

Whereas many content management system do not make a difference between the structure of data presented to the user and the structure of content data, ERP5 relies on this difference. Data structure is defined through so-called “Propertysheets”. The goal of propertysheets is to share as much as possible data structure between different documents, though a standard vocabulary. For example, the quantity property is used to represent quantities of goods exchanged in packing lists but also the debit and credit values in accounting. A typical document in ERP5 isbased on 10 propertysheets. A typical propertysheet defines 8 properties. This means that any document in ERP5 has in average 80 properties, which is much more than what is common in document management or web content management.

Forms in ERP5 define how the properties of documents are presented to the user. A form usually displays a subselection of properties of the document as well as properties from related documents or from the current context. Forms can be grouped into reports and render the properties of a collection of documents, not just one.

In addition to forms and properties, ERP5 introduces categories, which can be considered as hierarchical vocabularies or nomenclatures. Categories define in any ERP5 instance the core structure for reporting (ex. inventories, profits).

ERP5 Simulation is at the core of its design. Simulation consists of recursiveley rewriteing a single movement into a list of movements according to a business rule. A movement which represents and order is rewritten into a movement which represents a packing list which in turn is rewritten into an invoice movement, an accounting movement and a payment movment. Rewriting rules are also used to rewrite a production order movement into its individual components and operations, which is the usual MRP approach.

Rewriting rules are independent of the order in which business documents are validated. In certain business, payment is validated first, then order can be confirmed and goods shipped through packing lists. In other businesses, orders are confirmed, goods shipped, invoice issues and payment happens a couple of weeks after invoicing. Business Process models are used in ERP5 to define the order and time constraints between the different simulation movements generated by rules.

This dual design is very powerful. It makes rule more generic, more configurable. It simplifies the configuration avec complex back-to-back ordering processes which greatly depend on context. In addition to rules and business processes, ERP5 helps users handle situations in which “what was suppoed to happen” does not happen in reality, such as different quantity delivered, delay, backoder. ERP5 introduces “Solver” software components to embed intelligent logic and satisfy business rules in case of divergence between simulation and reality.

ERP5 current generic scop is quite wide: financials, trading, production management including MRP, project management, customer relation management, document management, knowledge management, high performance web sites, business process management, human resources. Each generic feature has been tested under real conditions and lead to a success story. Some generic features of ERP5 are also now part of a standard SMB configuration, a shrinked wrapped, software as a service (SaaS) version of ERP5 designed for small companies and for overseas subsidiaries of large companies.

ERP5 development guidelines are based on the idea that “prevention can not wait” because preventing is always more cost effective than repairing. Prevention is based on testing: unit tests, functional tests, performance tests and naming convention tests.

ERP5 unit tests cover abstract use cases of ERP5. Some of them are very much “unit” in the original sense of unit tests. Others use the unit test framework of ERP5 to simulation business test cases without taking into account user interface issues. There are now 4920 such unit tests.

ERP5 functional tests cover user interface. All base widgets of ERP5 are tested through functional tests. In addition, ERP5 functional test framework is used to test all ERP5 tutorials part of the OSOE programme.

ERP5 performance tests make sure that ERP5 performance does not decrease. This is very important because in many projects, extra features and genericity lead to 20% performance decrease every 6 months, which means a 300% slowdown in 3 years. ERP5 performance tests test basic user interface responsiveness and scalability of concurrent usage.

ERP5 naming conventions make sure that the code of ERP5 respects the naming convention guidelines in addition to some common python coding conventions.