ERP5 current generic scope 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 the ERP5 provided by Vifib (www.vifib.net), a shrinked wrapped, software as a service (SaaS) version of ERP5 designed for small companies and for overseas subsidiaries of large companies.

Little by little, all generic features of ERP5 will become part of the ERP5 provided as a Service.

ERP5 current scope is also include several features to handle web sites, documents and also a web office, named UNG Docs (http://www.freecloudalliance.org/project/ung). The UNG project intends to provide a complete alternative to proprietary cloud computing solutions, starting from enterprise applications and ending with search engines.

The UNG business template is a Web theme which provides UNG as part of ERP5. It announces a new kind of business templates which we call “application themes” and which are meant to provide to the end user the ERP5 features through a different User Interface experience. Themes could be created to mimic Salesforces.com experience, Facebook experience, etc. if it proves to be useful, or to create original experiences as it was the case with Cloudooo (www.cloudooo.com).

ERP5 supports a variety of vertical markets: banking, apparel, health, software publishing, consulting, software development forge, e-government, e-commerce and Cloud Computing. Most business templates designed for vertical markets have already been put in production and lead to a success story. Nexedi is using for its own purpose, including to wide commecial offers, the “Consulting” business template.

Latest developments in ERP5 relate to cloud computing. ERP5 is now becoming a billing platform for PaaS providers. The “PaaS Engine” business template is the one which is used to power TioLive (www.tiolive.com) and which is the core the of “Compatible” research projet in France Cloud Computing collaborative programme.

ERP5 is used by BetEire Flow, the Irish subsidiary of Sanef Group, to implement one of the largest mission critical customer support application in Ireland.

ERP5 is used since 2007 by Infoterra GmbH, an EADS subsidiary. This project is called TSXX. Infoterra is successfully using ERP5 for having an overview of all their business sales of images produced by two Radar-X satelites.

ERP5 is powering the French Open Data Portal called “Data-Publica”. The final goal of the platform is to serve as a market place between organizations wishing to publish data (the editors) and companies or individuals (the developers) wishing to use this data to develop mobile or Internet applications.

ERP5 was deployed by Nexedi in a Central Bank, to manage the monetary system of 80 million people in 8 countries. Never before has an open source project reached this level of strategic mission critical application. ERP5 Banking is available for download to the 250 central banks worldwide, to free their economies from proprietary software vendor lock-in.

More information about other projects listed, access www.erp5.com web site

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 even runs on embedded Linux distributions such as Meego.

ERP5 supports most relational databases, including MySQL, PostgreSQL, Oracle, Ingres, Sphinx, etc. MySQL database is the favourite for fast transaction management. Ingres Vectorwize is the favourite for data mining. Sphinx is the favourite for full text search indexing.

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.

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 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.

It is suprising that ERP5 approach is still not widely copied. The only similar case we know is an enterprise application developped by J-P. Figer for “Groupe La Poste” (France) following agile techniques and a search engine based approach which achieved 4 (XXX) times higher productivity that usual approaches.

ERP5 uses concurrent programming techniques inspired by Actalk, one of Jean-Pierre Briot's research in the 90s. Jean-Pierre Briot belongs to the French school of reflexive object programming which originated with Pierre Cointe and created at the end of the 80s many fundamental concepts which are called today “aspect oriented programming”.

ERP5 owes a lot to Actalk and to reflexive programming. ERP5 activities are a simple translation and simplification in python language of what Briot created in Smalltalk. With activities, ERP5 can distribute a heavy calculation on an elastric number of servers. Running a process on a list of a million documents can be accelerated by using a hundred servers and requesting each server to process ten thousand documents. The example code above shows that using such approaches in ERP5 only requires to add the word activate before calling the process. People sometimes view this approach as a kind of HADOOP, one of the approaches used extensively by Google, although it is a bit different.

It is surprising that ERP5 is still one of the few business applications to follow this model; although it is known to be a very efficient approach to make applications scalable and although all large Web services are based on such an approach. Yet, we found recently that another company, Activeon, had been following the same path as ERP5 for financial applications.

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 handled 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 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 includes two more innovative approaches: interaction workflows and dynamic accessors. Interaction workflows derive from Smets PhD (199X) “Actor Observer model” and provide a solution to integrate heterogenous component which is more efficient and flexible than event based approaches which originated in the 80s. Dynamic accessors provide a way to translate a data model into methods without any human coding involved.

Interaction workflows can be used to add interaction events to existing software components without changing their source code. They derive from the idea of “Observer”. They are implemented though a combination of dynamic subclassing and callable instances. Unlike event systems such as the one provided by ZTK and unlike “signals and slots” provided by Qt, interaction workflows are only fired whenever they are used. Any class method can act as an interaction event. Adding a few interactions to a collection of tens of thousands of interactions only costs the price of those few interactions and requires to extra code. This is why interaction workflows in ERP5 and much more flexible than event systems and more efficient.

Accessor generation is used to turn any property of ERP5 data models into a getter (ex. getFirstName), a setter (ex. setFirstName) and a tester (ex. hasFirstName). Thanks to getters, it is easy to add interactions to data access. It is also easy extend data access behaviour and to integrate external data by emulation the API of an ERP5 document.

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 more than 4000 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.

NEO will become the default ZODB storage for ERP5. NEO is an implementation of ZODB which eliminates any single point of failure and is designed for maximum scalability. With NEO, ERP5 can be used to implement the largest collaborative web sites (email, social network, etc.) and the large ERPs (banking, insurance, state payroll).

Although NEO provides redundancy for storage, it provides nothing in terms of indexing. MySQL will remain in the foreseable future ERP5 default database, with Ingres Vectorwize complementing it for data mining applications and reporting. Full text search will be based on Sphinx for European languages and Mroonga for Asian languages.

Combining multiple indexing technologies and multiple indices in the same technology will be the favoured approach to reach scalability and distribution at the level of the Catalog.Specialized catalogs for a subset of users could even be created as a way to partition an large index in smaller ones and reach higher performances on huge systems.

All ERP5 development will move to Web based tools. ERP5 will provide to developers a selection of Web based text editors, including a Javascript clone of Emacs and vi. Wizards will be created for each “How To” procedure which currently exists in ERP5 developer documentation, thus making such documentation useless. Such wizards actually already exist and are used to accelerate ERP5 training during OSOE sessions in universities.