View source | View content page | Page history | Printable version   



Openbravo Modules , Packs and Industry Templates - Functionals Specifications


An Extension Module is a piece of additional functionality that can be deployed optionally and independently on top of Openbravo ERP. Examples of modules are: additional reports, additional windows, connectors, content packs (translations, chart of accounts, list of tax codes, product categories, etc).

The experience of the user deploying modules should be similar to the one of Firefox plugins: you should be able to browse a catalog of modules, install, deploy and upgrade them directly from within the Openbravo ERP Administration UI. You should also be able to uninstall modules.

A developer of an Extension Module should be able to package and deliver a module independently from the rest of the Openbravo ERP content, meaning that they should be able to package modules with a delivery mechanism that only includes files and metadata that they are responsible for. Modules can be released with any license that is compatible with the Openbravo Public License. Finally, the author of an Extension Module should be able to indicate which versions of Openbravo ERP are compatible with it and which other modules, if any, it depends on. The installation of an Extension Module should validate that these dependencies are met.

All custom development (any development which is not a core contribution) done by partners or by end users should be conceived and developed as an Extension Module. This will make it easier for people to contribute to the community what they have developed for themselves. Usually people develop interesting functionality for their own usage and only as an afterthought they are willing to contribute it to the community, so this code promotion -from customization to module- should be supported by the platform.

In addition to Extension Modules, Localization and Verticalization Packs are defined.

Users should be able to apply more than one Localization and Verticalization pack on the same Openbravo ERP instance.

Finally, Industry Templates are a bundle of Openbravo ERP, one or more Verticalization Packs and a predefined configuration.

Openbravo modularity.png


The purpose of modularity is to make it easier to contribute to Openbravo ERP by allowing distributed and decoupled development and maintenance of optional features by Openbravo Community Contributors. Efficiency during the development cycle and simplicity and reliability when users install/uninstall modules are of paramount importance.

The purpose of a Localization or Verticalization Packs is to put together optional features -modules- to support a specific geography or industry.

The purpose of an Industry Template is to shorten the implementation cycle by delivering fully preconfigured systems that allow customers to go into production with only minimal additional configurations, by providing a one-button delivery of everything that is needed to operate Openbravo ERP in a given industry. A secondary goal of Industry Templates is to enable partners with industry specific expertise to package their expertise in the form of a template and to distribute it to the whole Openbravo ERP user community.


This project aims to enhance the Openbravo ERP platform to support modular programming. No more and no less. There are some other interesting features -such us customized behaviour by client in a multi-tenant environment or business events support- that are not supported yet in Openbravo ERP platform and that would greatly improve the user experience when developing modules or Industry templates. This features are out of scope in this project but are requests for future improvements.


Design Considerations

This project has a huge scope and has a high level of complexity. To minimize risk of unexpected issues it has been designed following a restrictive approach: modules are defined as simple and restricted as possible while supporting standard extensions and customizations, giving priority to reliability over versatility.

Industry Templates is about reducing the implementation time and cost and lowering the barriers of adoption of Openbravo ERP. Because of that, the user experience is paramount important. It must be very easy for a user not having technical or system implementator skills and having very little knowledge of Openbravo ERP to select and deploy an industry template.



This project depends on:



Application Dictionary Component
They are the basic elements that altogether compose the Openbravo ERP application. They are used by other components and software resources. Tables, columns, fields, messages, etc. are application dictionary components. For example a java class (which is a software resource) can make use of some tables, columns and some messages to perform a task that reads and processes information from those tables and shows a message depending on the result.
Software resource
SW resources are the Openbravo ERP objects that cannot be defined within the application dictionary. They are stored as files in a directory tree. There are two kind of SW resources:
Reference data
Data that describes referred by transactions that tend not to change on a very frequent basis. It also can define security elements as roles and their granted objects. This data can be defined to be shared among all the clients in the application (System), to belong to a single client and shared by all its organizations or to belong to a single organization within a client.
Translation files
This is a special type of reference data but it is not treated as standard because currently Openbravo ERP has processes to handle it. Translation files includes translations to a language for Openbravo ERP elements in XML format.
Chart of accounts
This is a special type of reference data but it is not treated as standard because currently Openbravo ERP has processes to handle it. Chart of account includes information about accounting structures (the accounts and their hierarchy) in CSV format.
Configuration script
A set of changes in data that, when applied to an Openbravo ERP instance, supports a specific set of business processes. It modifies application dictionary elements' attributes in order to make the application behave in a different way than it would do if the script were not applied. It cannot modify any attribute but a fixed list of them to prevent meaningless modifications that could make the application not work. For example it's possible to modify the show attribute for a field to make this field not visible but it is not possible to modify the “table name” attribute for a table because it would make the table element to reference to another database table.
Any customization consists on new functionality and configuration modifications on top of Openbravo ERP core. Thus they can be expressed as templates: a bundle of modules (for the new functionalities) and a configuration script (for the configuration modifications).

Functional Requirements

User roles & profiles

The user roles affected by this functionality are:

Openbravo Developer
This type of users have a high level of professional education (computer science in most of the cases) and have a deep knowledge of the core, product, and business processes. They are able to create new modules which require programming skills to develop new functionalities.
This type of users have a high level of professional education, have a deep knowledge of the business processes. Without need to know about programming they are able to create localization and verticalization packs, this is done setting up and adding data to an installation and exporting it as a pack.
Non-professional Functional Administrator
Typically a small business owner or trusted employee at a small business that is tasked with configuring the system to meet the requirements of the business. These users are typically computer-literate and very familiar with desktop applications and consumer web sites but does not have a formal education in computer science; they are therefore expecting a user experience comparable to the one of a consumer-grade application. They are very knowledgeable about the way their business work but are not familiar with ERPs and have never participated in a complex IT or formal business process re-engineering project. They can install on top of Openbravo ERP the modules, localization and verticalization packs and industry templates he needs to fulfill his needs, reducing thus the manual configuration to be done before start working.



Modules are content containers. They are able to add elements but not to remove or modify existent ones, the reason for this limitation is to keep it as simple as possible preventing consistence problems (a module modifying another one's elements that another one is trying to use as they were in the first module) and representation problems (in case modifications were allowed the information would look different depending on the module the user was working on). This limitation also makes modules more reusable, because a module purpose is only to add new functionality and a template aims to use modules and change the application behavior. To use these new functionalities, modules can be reused in different ways by different templates.

Modules are not allowed to contain other modules because packs are used for this purpose.

When a module is loaded in an Openbravo ERP installation, the information about this module is stored in the application itself, thus an Openbravo ERP installation will have information about all the modules it has installed.

The creation of a new module for its development will involve reserving a value and name for the module and with this information create the information about the module in the development application. As installing a new module will download it and add its information to the local modules repository, it is the same to install and to develop a module. This means that with only installing the module a developer is able to work on it locally.

The contents of this information for modules are:

The elements a module can contain are listed below.

Application Dictionary Components

All application dictionary components belong to a module (as core is another module), so a module can add new elements with all its attributes but it is not allowed to change other modules' ones.

This is the list of the application dictionary components:

  1. Table
  2. Column: columns by default belong to the same module the table they are defined in belongs to, but it is possible to define columns within a module for a table from another module.
  3. Window
  4. Tab: Tabs by default belong to the same module the window they are defined in belong to, but it is possible to define tabs within a module for a window from another module.
  5. Field: Fields by default belong to the same module the tab they are defined in belong to, but it is possible to define fields within a module for a tab from another module.
  6. Reference: the references a module can define are:
    1. List: list references are completely defined in a module: it is not possible for a module to add values to another module's list.
    2. Table
    3. Search: to be defined after search pattern application dictionary project implementation.
  7. Process and report
  8. Form
  9. Field Group
  10. Callout
  11. Auxiliary input
  12. Validations
  13. Menu entries
  14. Element: All the elements, except the ones that come from core, for all the columns and fields that are defined in the module (explicitly or implicitly) will be exported in the module. When a module is applied it will load the elements that are not already loaded.
  15. Import loader format
  16. Message
  17. Workflow

Robustness and consistency are key factors for modularity. When a module adds a new tab in a window defined by other module, or adds a new field in tab defined by other module, or adds a new menu entry there is a risk of conflict because other module could try to add a tab, field or menu entry in the same position. In those cases the seqNo of the tab/field/menu entry is calculated depending on the order the modules are installed.

Software Resources

Software resources include all the Openbravo ERP elements that cannot be defined in the application dictionary. They are stored as files in a directory tree within the standard Openbravo ERP tree, in the modules/module_name folder.

There are two main kinds of software resources:

  1. Database objects: These XML files which are inside src-db/database/model folder contain the physical description for the database objects that belong to the module. When a module is exported the module an object belongs to is decided following a basic naming rule: all object names will start by the module value followed by an underscore (_). Although tables and columns are described in the application dictionary and by this mean the assignment to a module could be done using that info without any need to use naming conventions, while Openbravo ERP physical database is directly created in the database itself instead of from Application Dictionary info then it will be required to "duplicate" the assignment in both the application dictionary and the database by naming convention.
    1. Tables: When a table is added by a module, a single XML file will hold all the structure information: columns, indexes and constraints. A table will be included in the module in case its name follows the naming convention rule (it starts with one of the module database prefixes and underscore _) and its application dictionary associated element module is the same one, other case an exception should be raised.
    2. Columns: If a column is added by a module to a table that is defined by another module, an XML file in the new module will be created for this column. This file will contain information only about this column and not for the whole table. The physical order the column will be created when applying the module may differ from the original one: first must be applied the module where the table is defined and afterwards the one that defines the column. This column will be added after the rest of columns. Although columns defined in the same module that their table does not need to follow the naming convention. The ones defined in a different module need to avoid naming clashes. When exporting the module a rule like in the table will be checked and in case the module defined in the application dictionary and the one in the column name do not match an exception will be raised.
    3. Indexes: Here will be defined indexes for tables from other modules.
    4. Constraints: Here will be defined constraints for tables from other modules.
    5. Triggers
    7. Functions
    8. Procedures
  2. Other files: These are other required resources as for example Java classes that implement new functionalities, jar files required by the Java classes, Pentaho components, etc.
Reference Data

Reference data describes information referred by transactions that tend not to change on a very frequent basis. It also can define security elements as roles and their granted objects. Additionally, in some cases, it can make sense to maintain some sample data as part of a module to be able to test it.

Reference data is not standard for all the modules: information that is required for one may be meaningless for another one. Thus when a module is defined it is necessary to set up the data that will be exported as its reference data, this will be done using different filters.

As references are not a fixed set of data they must be configured by the developer that is creating the module. This configuration consists of the selection of the tables to be exported, the filters definition for these tables and the type of reference (system, client or organization). When the export is done, in order to preserve referential integrity, not only the selected tables but also their referenced elements will be exported.

For example, if a module needs to export as reference data the taxes in the application, developers set c_tax table to be part of the reference (additionally they could set a filter, for example all the taxes with name like 'VAT%') and the reference type as client to be imported within a specific client. When it is exported the export tool will try to export data in C_Tax table that fits the filter, as C_Tax table references to C_TaxCategory the records in this one that are referenced by C_Tax will also be exported, additionally C_Tax table can have references to C_Country and C_Region elements, which will also be exported, but these ones will be defined also in core so when they are tried to be imported the core ones will remain and the new ones will not be imported.

With the previous definition database referential integrity is guaranteed, but it is not guaranteed that reference data object are complete. Following the example: tax object is defined by an additional table: C_TaxZone which defines the zones a tax is applicable and points to C_Tax, without the information in this table a tax object could not be completely defined, but the exportation tool is not “smart” enough to decide to export also this table, so is the developer who must also add this table to the filters in the reference data definition. This limitation for the exportation tool is because C_Tax do not point to C_TaxZone but the last one points to the first one, in case the tool exported also references to the main tables (the one defined in the filter) it also would try to export all the tables where the object is used in (including for example all the invoices that include this tax), this problem would be solved in case Openbravo ERP defined business object, this definition would include all the tables necessary for a complete object definition, but as currently they are not defined and is the developer who must take care about this.

There are three kinds of reference data: system, client and organization:

When information is exported as reference data some exceptions must be taken into account:


Packs are module containers. Each module should add a single functionality and packs should be used to group them in order to create a set of functionalities that makes sense for a particular usage.

Because of the functionality they include there are two special kind of packs:

Industry template

An industry template is composed by a pack and a configuration script. Thus industry templates can change the pack's standard behavior. The purpose of industry templates is to wrap in a single object the packs and configuration necessary for a specific kind of industry.

Configuration script

Configuration script is the way to perform modifications to core and modules behavior. A configuration will never add new elements, it just will modify some attributes for existent application dictionary components (defined in other modules, including core). It cannot modify all the attributes in these components but only the ones that make sense to be modified, the purpose of this limitation is to partially guarantee the modifications performed by a configuration script do not break existent functionalities. For example: for a table it is possible for the script to modify the default window it will use (which is a change on the application behavior) but it is not allowed to change the physical database table it points to (because it would make existent modules not to work as they are expected to do). Below are listed the attributes a configuration script is able to modify.

Application dictionary element Attribute Database column Comments
Table Window AD_Table.AD_Window_ID
Po Window AD_Table.PO_Window_ID
Deletable records AD_Table.IsDeleteable
High volume AD_Table.IsHighVolume
Column Reference AD_Column.AD_Reference_ID This modification is prone to cause problems if the data type for the new reference is different to the initial one.

An example where this makes sense is a module that creates a new search reference, in this case the columns that can use this search would be modified to this reference.

Reference search AD_Column.AD_Refeference_Value_ID
Mandatory AD_Column.IsMandatory This only should be modified in case it is not mandatory in the model.
Updateable AD_Column.IsUpdateable
Read only logic AD_Column.ReadOnlyLogic
Identifier AD_Column.IsIdentifier This can be modified in case identifiers are not used by reference data to identify records for non-system types.

This modification will also affect to AD_TABLE.SQL_RECORD_IDENTIFIER

Filter column AD_Column.IsSelectionColumn
Callout AD_Column.AD_Callout_ID
Stored in session AD_Column.IsSessionAttr
Element AD_Column.AD_Element_ID
Window Window type AD_Window.WindowType
Tab Sequence AD_Tab.SeqNo Although it should be possible to change the order the tabs appear in, sequences should not be treated as a number but as a reference to previous elements.
Default edit mode AD_Tab.IsSingleRow
Read Only AD_Tab.IsReadOnly
Process AD_Tab.AD_Process_ID
Filter clause AD_Tab.FilterClause
SQL Order by AD_Tab.OrderByClause
Field Displayed AD_Field.IsDisplayed
Read only AD_Field.IsReadOnly
Display logic AD_Field.DisplayLogic
Display length AD_Field.DisplayLength
Display on same line AD_Field.IsSameLine
Record sort no. AD_Field.SeqNo
Is first field focused AD_Field.IsFirstFieldFocused This modification can make to have more than one field set as first focus in the same tab. This can cause not to have the focus in the field that was supposed to be in.
Show in grid view AD_Field.ShowInRelation
Sequence AD_Field.SeqNo Making reference to the previous element.
Field group AD_Field.AD_FieldGroup_ID
Central maintenance AD_Field.IsCentrallyMaintained
Name AD_Field.Name Just in case it is not centrally maintained
Description AD_Field.Description
Help AD_Field.Help
Table reference Order by AD_Ref_Table.OrderByClause
Menu Order AD_TreeNode It will be exported as references to other elements.
Element Print Text AD_Element.PrintName
Purchase Order Name AD_Element.PO_Name
Print Name on Purchase Order AD_Element.PO_PrintName
Purchase Order Description AD_Element.PO_Description
Purchase Order Help AD_Element.PO_Help

Additionally to the listed attributes in all the application dictionary elements the is active, name, help and description attributes are modifiable in case they exist. Also in case the attributes in the list have translation this can be included in the script.

The way to obtain the configuration script is using a tool that receives as a parameter the industry template in which to include the configuration script. This tool calculates the differences between the running instance and the installed one and generate the script. Additionally to this automatic process a customization script can be manually edited using an scripting language to be defined.

Central Repository

Openbravo will maintain a central repository with information about all the registered modules, packages and templates. This will allow to guarantee that there are not duplicated module names and values, as well as it will facilitate to browse for existent modules in a central place.

The information to this central repository will be submitted when the module is registered. This repository will store for each module its historic values for versions and the dependencies it has for each version.

Naming and packaging rules

Modules, packages and templates can be developed by anyone independently without (much) care about other ones developments. In order to prevent possible naming clashes among different modules some simple naming rules must be set.

The first step before any new module development should be to reserve a naming space for the module. This will be done checking whether the desired name and value is already registered in the central repository, if it is not used the following step is to register it in the repository to make sure they are used only by the new module and not by another one.

Once the value for the module is known it is possible to start developing it following this:

Openbravo ERP base directory
     |  |-src
     |  |  |-mod1 [mandatory]
     |  |     |-myPackage1
     |  |     |  |
     |  |     |  |
     |  |     |  |-Template.html
     |  |     |  |-Template.xml
     |  |     |  |-Database.xsql
     |  |     |  |-...
     |  |     |-myPackage2
     |  |        |-...
     |  |-web
     |  |  |-mod1  [mandatory]
     |  |    |-...
     |  |-src-db 
     |  |  |-[These contents are automatically populated by the exportation tool]
     |  |-...

Any customization consists on new functionality and configuration modifications on top of Openbravo ERP core and industry templates.

It is possible to express any customization as an Industry template, this is as a bundle of modules and a configuration script taking into account the already applied industry templates.

Thus they can be expressed as templates: a bundle of modules (for the new functionalities) and a configuration script (for the configuration modifications).

What can and cannot be done

Let's explain through some simple examples what is allowed and what is not for modules, packs and templates.

Change the invoice report clicking the toolbar print button

Define a new Jasper Report for invoices and associate it with the print button in the invoice header toolbar.

What cannot be done

This cannot be done with a single module, because it includes a modification in the standard behavior defined in core. It must be a template that includes a module defining the new functionality (the new report) as well as a configuration script that associates the new report to the toolbar in the invoice tab (thus modifying the standard behavior for this tab).

How to do

The steps to create this reports are:

  1. Create a new module to add the new report functionality.
    • Register the new module to obtain and reserve a valid value.
    • Create the new Jasper Report.
    • Create the process that calls the report.
    • Export it as a module.
  2. Create the template.
    • Register the new template to obtain and reserve a valid value.
    • Add the module to the template definition.
    • Associate that process to the tab in order to call it from the tab.
    • Export the configuration script.

On top of the module, localization modules can be developed to contain different translations for the report.

Tax Payment Functionality

Although Tax Payment Functionality is currently built-in the ERP core product, let's suppose it were not and we would wanted to develop it as a module (simplifying the current development).

This functionality includes:

Based on this simple module, new ones can be created to include new reports to show this information, and localization ones to translate it to different languages. In order to keep this example as simple as possible only the first part will be described.

How to do

This can be accomplished as a simple module, to do so:


The contents the module will have are:

Rapid order line insertion

This functionality allows to insert rapidly order lines from header, this is done using a new manually developed user interface callable from the order header tab.

Once this module is applied the classical way to insert new lines (through the lines tabs) can become useless.

What cannot be done

As a module it can add the functionality but not modify the existent lines tab to hide it, this would be feasible with a template.

How to do

Let's define the module that adds the new functionality and the template that hides the standard order line tab.

Import Taxes Process extension

Import Taxes is a java process that reads taxes defined in a csv format file, processes this information and loads it in the application.

This process can be modified in order to load additional information.

What cannot be done

It is not possible for modules nor for templates to modify java processes, so this is not doable as it is defined.

How to do

The way to do it is not modifying it but implementing a new class to do the new functionality, this class could extend the original one to make use of some of its features but it will never modify it.

Once this is done a new process should be created to map this class.

This can be exported as a module.

Additionally to change the behavior of the button that calls this process a new template with a configuration script to do so must be defined.

Invoice post modification

Invoice post processes invoices, it performs different operation depending on the invoice and the application configuration.

Modifications in the manner this process is performed may be wanted.

What cannot be done

This example has the same problem as the previous one: it is not possible to modify an existent process.

How to do

The way to do it is not modifying it but implementing a new PL/SQL procedure to do the new functionality, this procedure could use the existent one but never modify it.

Once this is done a new process should be created in the application dictionary to map this class.

This can be exported as a module.

Additionally to change the behavior of the button that calls this process a new template with a configuration script to do so can be defined.

More examples about what cannot be done

Templates are not allowed to do any modification that implies changes in application dictionary component attributes that are not listed in the configuration script section.

Some examples of this are:

A Complete Example

The Scenario

To better illustrate the need for Industry Templates, let's consider the example of a small US-based non-profit organization that coordinates the work of a group of volunteers that provides services to inner-city youths.

The primary source of financing comes from voluntary donations of members that pay an annual membership fee. There are three levels of individual membership (standard: $25 - silver: $50 - gold $100) and one level of business membership ($75), but the organization accepts donations of any monetary amount.

Members are recruited through membership campaigns and registered in a database; on an annual basis, the organization mail reminders to all the current and past members to solicit a renewal of their donation.

Membership fees can be paid either by cash, check or by credit card using a payment service.

Given the voluntary nature of the memberships, they are not invoiced but a receipt is issued when the payment is received.

The organization also publishes a newsletter which contains advertisements which are sold at a price that depends on their size. Business members have a discounted price on ads. Advertisement is sold using a standard sales cycle: advertisers place an order, they are invoiced, they send a payment and they receive a receipt.

Occasionally, the organization receives donations from other non-profit organizations and makes donations to other, smaller organizations.

The organization has a single bank account where it deposits all the donations and from which it issues all the payments by check.

The accounting for all transactions is done on a cash basis.

Openbravo ERP Implementation

In order to implement Openbravo ERP for this organization, the following configuration is needed:

Reference Data All the following reference data is client type:

All the above data, with the exception of the entries marked with (*) is generic and reusable with minimal modifications by other organizations in the same industry.


The following two modules, would be very useful for this sample organization:

The Industry Template

In this example, the industry template would be made of the following elements:

Users should be able to download the template and load it to their installation of Openbravo ERP.

Reference Data



This industry template contains two modules that provide new functionality.

Financial Institution Connector

This module implements a java process that, using an external java library that downloads bank statements in OFX format, creates bank statements.

It is composed by:

Paypal Connector

This module implements a java process that, using an external java library that downloads information on donations received through Paypal, checks if an invoice has been payed using Paypal and in case it has been checks the invoice as payed.

It is composed by:

Business process definition

The processes related to this project can be better described depending on the role performing the process: developers will develop and maintain modules, consultants will create and maintain packs and industry templates, users will install/uninstall modules, packs and industry templates.

Code in a module/pack/industry template should be managed using standard development tools and methodologies such as a SCM (eg. subversion), branching policies, etc.

Development and maintenance of Modules

To develop new functionality on top of Openbravo ERP developers can:

Modules also require maintenance, in the same way that Openbravo ERP core does. People in charge of a module can release maintenance patches -to fix bugs within a version- or updaters to move the module to the next version.

So other development tasks that can be done in the maintenance process are:

Each time a user tries to update a module in his/her instance to a new version the upgrader requires that all dependencies are satisfied. So each time a module releases a new version all modules that depend on it should check that the module still works on the new version and if not fix the problems and release a new version compatible with that. If no fix is needed there is no need to release a new version but update the dependencies including the new version.

In some cases it is needed to move content from one module to another (from a customization to a module, from a module to core or the other way around) or merge two modules into one. In those cases both modules -the one that donates the code and the one that receive it- require to release a new version. The promoted code needs to be refactored at least to support the naming rules. Since the Central Repository will keep track of this changes there is nothing new -from the developer perspective- to be done regarding code promotion.

A development environment can support many modules at the same time.

Localization/Verticalization Packs development and maintenance

To develop a new Localization/Verticalization pack consultants/developers can:

Packs require little maintenance since usually it is done through its modules. But a new version of Pack could be released adding or removing modules from it.

So other development tasks that can be done in the maintenance process are:

A development environment can support many Packs at the same time.

Industry Templates development and maintenance

To develop a new Industry Template consultants/developers can:

Industry Templates also require maintenance in the same way that Openbravo ERP core does. People in charge of an Industry Template can release maintenance patches -to fix bugs within a version- or updaters to move the Industry Template to the next version.

So other development tasks that can be done in the maintenance process are:

A development environment only supports one Industry template at the same time.


A customization in Openbravo ERP can be consider as an Industry Template from a development point of view. All new functionalities developed within the customization will be assigned to a "custom" module that all Openbravo ERP instances will have (this modules should be validated/registered in the Central Repository to get a global unique identifier from the beginning). This module is considered to be installed after any other module, pack or industry template that could be installed in that instance. There will be also a "custom" industry template to store the configuration script for any change to AD components done during customization. It means that the whole customization is developed in the same way as if it were a module + an industry template. It facilitates eventual promotion of that functionality to real modules or even core.

Installing, uninstalling and updating modules, packs and Industry Templates

The most important processes in this project are the ones related to users:

Modularity provides a clean model for upgrading/updating any module (including core), pack or industry template installed in an Openbravo ERP instance: just replace the code being upgraded/updated by the new one and rebuilding the system from sources.

User stories

This user stories will take as basis the previously described complete example.


A company based in the UK requires to connect with financial institutions to download bank statements in OFX format to upload them in Openbravo ERP. Mike is an IT employee in this company and in is charge of the development of this connector.

First of all, Mike looks in the Openbravo module central repository for an existent OFX connector adaptable to his needs, but he is not lucky and nothing helpful is found, so he decides to implement a new module. He creates in his Openbravo development environment the new module and registers it to obtain a unique identifier. He develops the module (which consists in a jar library to make the connection and an Openbravo process that uses it) and customizes the company's ERP to use this new module. When he's finished his work, he decides to share with the community this module, he thinks the customization needed to make use of it in the ERP is very specific for his company but the connector is quite generic and could be used for anyone else, so he uploads it to the Openbravo AppExchange.

In a similar way Mike did, Cristina, who is working for another company in Spain, creates another module to pay invoices using PayPal and uploads it to AppExchange.

Tony is a volunteer in a non-profit organization and as he has some experience with Openbravo ERP he is asked to try to adapt the standard ERP to the organization needs (which are described in the example). In this case he is quite lucky, because although he finds in the Openbravo AppExchange repository the two modules he needs to adapt Openbravo. So he downloads and installs them on top of Openbravo ERP core product. He thinks it would be a great idea to package these two modules, add some useful referential data and create an industry template with the configuration he needs because it could be useful for other similar organizations. So he does the customization he needs (using the two modules, creating some referential data and making some configuration adjustments) and afterwards he packages all this stuff as an industry template and uploads it to the AppExchange.


José is the a board member for a non profit organization that has been managing its operations using a combination of spreadsheets (to track newsletter ads), ad hoc databases (to track donors) and commercial off the shelf consumer grade accounting software (to manage accounting). This data fragmentation leads to a lot of complexity in the communication within the organization, loss of revenue, and members.

To address these issues, José decides to consolidate the IT infrastructure using an ERP. After doing some research he finds that Openbravo is adaptable enough to fit his needs. So he download the standard Openbravo ERP product. After this he browses in the AppExchange for modules or templates to adapt the standard product to the needs of his organization. He finds two templates for non-profit organizations (Tony's one and another one), as he is not very sure which of them would be better for him he decides to test both.

He installs the first one using a friendly user interface and he tests it. The he installs the other template on top what he has, he realizes this new template fulfills all the requirements he had, so he uninstalls the first module using the same user interface and with some minimal setup configurations is able to start working.

Module promotion and maintenance

Openbravo team for the next ERP release decide that Tax Payment Functionality, which in previous versions was built-in core product, should be maintained as a different module. So they create for this new release a new Tax Payment module removing it from the core product, this includes moving tables from one module to another one (Core to Tax Payment).

When Openbravo team publish the new release, Mike and Cristina check their modules to ensure they still working properly. Mike's one works fine so he only has to update the decencies list for his module to add the new core version, Cristina has to do some adjustments so afterwards she publish a new release for her module that is dependent on the new core version. Tony is told by the application to upgrade core product and Cristina's module because there are new releases for them, he tests his template and as it is working he does like Mike, just update the dependencies list to Cristina's new version.


When new Openbravo ERP version is released José downloads the upgrader, when he executes it a message appears saying that all the modules he has installed are not compatible with the new release and there are no new versions for them, he can follow upgrading core with the risk of the old modules stop working or wait until these modules are upgraded, he decides to wait. A week later he tries again and, as Tony has finished his work, now the upgrader says there is a new version for Cristina's module that should be installed and ask for confirmation to do it. José also uses the Tax Payment Functionality so it has data in these tables, the upgrader notices about that and tells José that information is no longer within core and if he wants to maintain the data he has and that functionality he must install the new Tax Payment module, he accepts and the process continues. So what the upgrade process will upgrade Cristina's module and core product and will install the tax payment module, all this from a single user interface.

Functional requirements based on business processes

Development of Modules
Num Requirement Importance Status Comments
1.1 Edit (create, read, update and delete) module information in the Application Dictionary. Define module content and dependencies. Activate an installed module for development Must have To be started
1.2 Register a module in the Central Repository to avoid duplicated names. Show a flag (not editable checkbox) in application dictionary for registered modules and provide them a password for management purposes. Must have To be started
1.3 Assign AD components to modules: include a mandatory field pointing to the module they are assigned to. The AD components that can be assigned to a module are described here Must have To be started
1.4 Add software resources to a module package. There are two types of software resources:
  • 1.4.1 Database objects: assigned to the module by naming convention. DBSourceManager will export the database objects to xml files located in the module package. It will validate that all the objects are exported to active modules
  • 1.4.2 Other files (java, jar, javascript, etc.): directly packaged by the developer in the module package
Must have To be started
1.5 Customize Initial Client Setup and file loading processes (Import for product, business partner, invoices, ...) using adaptors Nice to have To be started
1.6 Include a language pack into a module as System level reference data. The development and maintenance of language packs will be done independently from modules, but translation packs can be attached to modules. Mark that module as a "Translation pack" container Must have To be started
1.7 Include a chart of accounts into a module, as a resource to be used by the Initial client Setup. Mark that module as a "Chart of accounts" container Must have To be started
1.8 Include one or many csv files in a module to be automatically loaded using Import file tool (product, business partner, ...) at installation or Initial Client/Organization setup. Mark that module as a "Reference data" container Nice to have To be started
1.9 Get an xml file containting reference data and include it in a module as described here. Mark that module as a "Reference data" container at System, Client or Organization level. The tool to export data from an instance to a xml file is develop in the DAL project Must have To be started
1.10 Define a pack (eg. localization or verticalization) as a set of modules Must have To be started
1.11 Define an Industry template as a set of modules installed in the instance. Generate the configuration script for that Industry template as a difference between the original code installed -including modules- and the instance. Export the configuration script in the Industry Template package Must have To be started
1.12 Build process (database create or update and compile and deploy) for an instance with modules installed, managing all types of module content (AD components, sw resources, reference data, packs, configuration script). Must have To be started
1.13 Package all module content in a self-contained compressed file that is used by the Module Manager Console to install/update that module. Support all types of modules (modules, packs, industry templates) Must have To be started
1.14 Publish a new version of a module in the Central Repository Must have To be started
1.15 Update public information of a module in the Central repository:
  • publish a new version for that module
  • Update other public information (eg. to include compatibility with new versions of modules it depends on)
Must have To be started
1.16 Developer's guide: documentation to explain the development cycle, processes and tools to develop, package and publish all types of modules (modules, packs, industry templates) Must have To be started
Module Manager Console

From the Module Manager Console (MMC) the user is able to see installed modules, update and uninstall them and search and install new ones.

Num Requirement Importance Status Comments
2.1 See installed modules in a tree structure (packs and Industry Templates as parent nodes of modules included in them). Show the list of installed modules pending to be applied to the instance Must have To be started
2.2 From the list of installed modules, see detailed information (full description, license, author, dependencies, ...) of any of them Must have To be started
2.3 See a report with the full installation history of that instance Should have To be started
2.4 Search for modules, packs and Industry Templates to be installed. Modules can be found in the web (Central Repository) and in the local file system. Must have To be started
2.5 Install a module. The MMC must guarantee the consistency of the instance (all dependencies must be present). Only one Industry Template can be installed. Must have To be started
2.6 Uninstall an installed module. The MMC must guarantee the consistency of the instance (all dependencies must be present) Must have To be started
2.7 Update an installed module. The MMC must guarantee the consistency of the instance (all dependencies must be present) Must have To be started
2.8 Scan the Central Repository for available updates on installed modules Nice to have To be started
2.9 Apply configuration (new installed modules, uninstalled or updated modules) to the instance. Create/update the database taking into account module content and eventual configuration script. Automatically load System reference data (eg. tranlations). Compile and reload the instance Must have To be started
Load module reference data at Client/Organization level

A module can include reference data to be loaded to clients or organizations in the instance.

Num Requirement Importance Status Comments
3.1 In the Initial Client Setup the user is allowed to choose from the installed modules that are Client reference data containers which ones of them are to be applied to the Client. The user is also allowed to choose the chart of accounts from the local file system in .csv format (as it is today) or from a "chart of accounts container" module. The system guarantees that only one chart of accounts is applied at initial client setup. Must have To be started
3.2 Apply to an existing client a "reference data container" module Should have To be started
3.3 Update reference data from modules applied to a Client Should have To be started
3.4 Initial Organization Setup: the user is allowed to choose from the installed modules that are Organization reference data containers which ones of them are to be applied to the Organization. Nice to have To be started
3.5 Apply to an existing Organization a "reference data container" module Nice to have To be started
3.6 Update reference data from modules applied to an Organization Nice to have To be started
Num Requirement Importance Status Comments
4.1 Migrate an old openbravo instance (previous to 2.50) to a modular structure. Export its customization as a module and industry template. Analyze the generated module and industry template and mark it as "not shareable" if it includes not allowed changes (eg. changes in a core stored procedure) Should have To be started
4.2 Adapt the "export language" tool to support modules Must have To be started

User Interface Mockups

Module development



Technical Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

Retrieved from ""

This page has been accessed 25,409 times. This page was last modified on 8 June 2012, at 05:28. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.