Projects/Modularity/Specifications

Languages:

Openbravo Modules , Packs and Industry Templates - Functionals Specifications

Overview

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.

Localization Packs are a collection of Extension Modules that provide functionality specific to a given country or geography.
Verticalization Packs are a collection of Extension Modules that provide functionality specific to a given industry or vertical market.

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.

Purpose

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.

Scope

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.

References

OSGi: a reference on how to implement a Dynamic Module System in Java
Industry Templates: an older project addressing a similar topic

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.

Assumptions

Dependencies

This project depends on:

UUID project
AppExchange/Openbravo forge
DBSourceManager and installer/upgrader tools

Constraints

Glossary

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:

database objects: they are XML files that persist the database physical model: tables, column, constraints, indexes, triggers, views, functions and procedures.
other files: these are non-database objects, they can be java classes, jar library files to be used from other classes, etc.

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.

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

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

Concepts

Module

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:

Public Name: It is a unique name for the module.
Java package: It is the name for the java packages that will be included in the module, it is also used to name the module itself.
'Database prefixes: It is a list of short (7 characters) identifiers for objects in database. This list can be empty in case the module does not include any database object.
Version: Modules are versionable, and this version will register the current installed module's version.
Description: A short description for the module.
Help: Help about what the module's purpose and usage. In conjunction with name and description will make possible to browse and select the desired modules to install.
URL: The URL where the module can be downloaded from.
Dependencies: Modules are dependent among them, at least every module will depend on the core (notice the core is treated as another module) but it can also depend on other ones. A module depends on other module in case it makes use of elements defined in the other one. Dependencies are defined as the module value and its version. The version is included because the fact a module depends on another one in a specific version does not mean necessary it will be compatible with the same module in another version. When a new version for the dependent modules is released, the module maintainer should have to check it is compatible with the new version, in case it is this dependency will be added to his module dependencies list, in case it is not he would have to solve the problems and release a new version for dependent on the new version for the other module.
Sequence: The order modules are applied may differ the data they import.
In development: This is a boolean value for development purposes. Only those installed modules with this value being true will be exported. This is done just for performance optimization because exportation process can be time consuming and a developer only wants to export the modules he is working in.
License: The license the module is released with.
Language: A module can be developed in any language and this value indicates in which one is developed, this means that all the user interface for this module is by default in that language. Fore more information look at Translation Management.
Requires translation: This check is true in case the module contains user interface objects that can be translated to different languages.

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:

Table
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.
Window
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.
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.
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.
Process and report
Form
Field Group
Callout
Auxiliary input
Validations
Menu entries
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.
Import loader format
Message
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:

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
6. Views
7. Functions
8. Procedures
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:

System: System reference data is the information that will be shared among all the clients in the application, it is imported once when the module is applied.
Client: Reference data can belong to a single client, making it possible to share among different clients in the same application. In this case when the module is applied the information remains in the module but it is not loaded in the database. When a new client is created using the Initial Client Setup, a list of modules with this kind of reference data will be shown and the user will be able to select those ones he wants the new client import. The usual way to import this information is when creating new clients. It is also possible to load it to an existent client although it is not the standard workflow, for this case graphical user interface will not be supplied and a consultant user should perform this operation using console tools, this limitation is due to the risk of the operation.
Organization: Organization reference data works in a similar way client reference data does, but it can be loaded for a concrete organization instead of client. There will be an Organization Setup that, like Initial Client Setup, will allow to select the modules with this kind of data to be loaded into an Organization.

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

Trees
Preference values: Preference values can assign an ID to another table, in case this table is also reference data and it is for client or organization, the ID cannot be directly set because it is generated when the module is uploaded. A kind of script to handle this problem is needed in this case.

Pack

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:

Localization pack: A localization pack includes all the required information to localize Openbravo ERP for a country. This information is composed by translation files, chart of accounts, taxes, country specific reports and processes, etc.
Verticalization pack: A verticalization pack includes all the functionalities required for an specific industry segment.

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:

Database objects. All new the names for the physical database objects to be included in the module must start by one of the database prefixes for that module followed by and underscore (_). For example if the module we are developing database prefix is mod1 and we want to create a new table in database it should be named something like mod1_tableName. An exception for this rule is for the columns, indexes and constraints defined within a table that belong to the module, in this case it is not necessary to follow any rule. But if columns, indexes or constraints are defined for a table defined in another module they must follow the rule, for example we want to add in our module (mod1) a new column to a table defined in (mod2) the column name should be mod2_tableName.EM_mod1_columnName.
Application dictionary components. No rules must be followed. Application dictionary components will explicitly assigned to one of the installed modules (notice that a module that is being developed is also installed in the application), in these elements naming conflicts will be solved making unique not only its name but the name in conjunction withe the module.
Software resources packaging. The root directory for all the installed modules is called modules and it is descendant of the root Openbravo ERP directory, below this directory there is another one for each of the installed modules, the name of these directories exactly matches the modules' value. Below this directory there is a replication of the structure in the root directory.
- Java packaging. Special attention must be payed to the way of packaging java classes must be done. They must be in the src directory for the module they are defined in. The first level of the package must be the module value, and after it there is not naming limitation. Thus the structure for an application with mod1 and mod2 installed would be:

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

Customization

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:

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

Tax register types with lines including tax and/or document type. This includes the creation of two new tables to maintain this information and a window with two tabs (header and lines) to manage the information. This is a setup window that should be inserted in the menu in Financial Management || Receivables & Payables || Setup.
Tax payment. In the header a business partner is selected as well as starting and ending dates, a create register button will create a header for each of the defined register types and a line for that header for each of the invoices with tax date between the two dates. To do this is necessary to create three new tables: one for tax payment definition (including business partner and dates), another one for the header of each tax register type and the last one for the lines. Additionally a new column in the invoice table is necessary to save the date for the tax.

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:

Register the new module to obtain and reserve a valid value.
Create the five new tables following the naming rules.
Create the new tax date column in the invoice table following the naming rules, note that a new column is added to a table from another module thus the column must be named following the rules.
Add all these new elements to application dictionary. Pay special attention to the new column in the invoice table, to be consistent it must be set in the new module in spite of the fact the table is defined in another one (core in this case).
Create the create register process which is a java class. This class must be created following the packaging rules described above.
Create a process in the application dictionary and associate it to the java class.
Create the two windows with their tabs and fields.
Add the entries in the menu and positionate it in the correct place in the menu tree.
Create a new field in the invoice header tab (note that this field which by default would be in the core module, must be set in the new module).
Export all this stuff as a module.

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.

The module
- Register the new module to obtain and reserve a valid value.
- Create the java classes and templates to implement the functionality
- Create a process and map it to the java class
- Create a new column in the order header table to hold the new button. Note that it is a column for another module's table so it must follow naming rules.
- Create the new column in the application dictionary and associate it with the new process
- Create a field in the header tab for the new column
- Export this as a module

The template
- Register the new template to obtain and reserve a valid value.
- Define the module to be inside the template
- Hide the lines tab
- Export it as a template

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:

Modify DB table name in a table: This is not allowed because would cause other modules to work in a way that may not be the expected one.
Key or Secondary key in a column: This field sets the primary key column for a table, it is not possible to modify other module's value because it is a basic information for the correct work.
Sales transaction in a window: Defines whether the window is for sales or purchases transactions, this cannot be changed because it define core behavior for the data, so changing it can change the behavior of other modules relying on its default value.
Table in a tab: Defines the table the tab works with. This is, again, a core information, if changed the tab would work in a different way.
Value in a list reference: Value is the actual value the application work with, usually processes use it and in case it is changed these processes would not work properly.

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:

A user role for the new client to only allow access to the following functionality:
- Master Data Management
  - Business Partner
  - Product
  - Price List
  - Import Business Partners
- Procurement
  - Purchase Invoice
  - Purchase Invoice Dimensional Report
- Sales Management
  - Sales Order
  - Create Invoices from Orders
  - Generate Invoices
  - Print Invoices
  - Sales Dimensional Report
  - Sales Order Report
  - Invoiced Sales Order Report
  - Orders Awaiting Invoice Report
  - Invoice Detail
  - Invoice Customer Report
  - Sales Invoice Dimensional Report
- Financial Management
  - ...
Define the business partner categories:
- Members
- Business members
- Board members
- Advertisers
- Suppliers
- Volunteers
- Non-profits
Define the following titles
- Mr.
- Mrs.
- Miss
Define the product categories
- Ads
- Services
- Other
A price list adjustment to represent the discount on advertisements for business members (*)
Define a GL calendar with quarterly periods
Define a bank account (*)
Define a cashbook for petty cash transactions
Define two remittance types
- Mail deposit
- Branch deposit

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.

Modules

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

Financial Institution Connector that downloads bank statements in OFX format.
Paypal Connector that downloads information on donations received through Paypal.

The Industry Template

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

The reference data
The two modules

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

Reference Data

???

Modules

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:

Application Dictionary Components
- Process: A process definition in application dictionary.
- Menu entry: A menu entry for that process.
Software Resources
- The process implementation, in this case because it is a process with non-standard user interface it will include also the interface so the files it will contain are: java class; this class will implement a servlet for the interface as well as the process itself, html template and xml for the user interface and xsql file that will be used to connect to database.
- The external library used by the class to download the information.

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:

Application Dictionary Components
- Process: A process definition in application dictionary.
- Column: A new column of button reference added to C_Invoice table, this column is used to hold the button that calls the process.
- Field: A new field in the Sales Invoice - Header tab for the new column.
Software Resources
- The java class that implements the process.
- The external library to check the Paypal that is used by the java class.

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:

register a new module in Openbravo Application Dictionary.
validate/register that module against the Openbravo Central Repository of Modules to guarantee the uniqueness of the module identifier.
assign new Application Dictionary components (tables, windows, processes, etc.) to the new module through Openbravo ERP UI.
include new standard sw resources -java files or libraries, web resources, etc.- in the new module package.
create new db objects -tables, stored procedures, triggers, etc.- following naming convention to assign them to the new module.
add a set of reference data files (including translation, chart of accounts or generic data) to the new module using an utility in Openbravo platform.
define dependencies in the new module with help from Openbravo UI that will show all installed modules.
define the version for the new module.
define the new module license as a compatible one with the licenses of all modules it depends on. Openbravo UI will help on that task.
export to a compressed file all module content -AD components, sw resources and reference data files- trough an utility in Openbravo platform. This compressed file can be used by the Openbravo installer to install the module in a clean environment.
test the installation of the new module in a clean environment to check it installs and works fine.
update the Openbravo Central Repository of Modules and optionally upload the installation file of the new module to Openbravo AppExchange to allow distribution through this channel.

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:

install a module in a development environment.
activate the module for development.
perform bug fixes in content assigned to a module.
test that those fixes work fine.
update dependencies and other module info.
update the major/minor version of the module.
export the module.
update the Openbravo Central Repository of Modules and optionally upload the new installation file of the module to Openbravo AppExchange.

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:

install any number of modules, packs and industry templates in their development environment.
register a Pack in Openbravo Application Dictionary.
define the list of modules, packs and industry templates included in the Pack from the ones installed in the development environment.
define the version for the new Pack.
define the Pack license as a compatible one with the licenses of all modules it includes. Openbravo UI will help on that task.
export to a file the Pack definition trough an utility in Openbravo platform. This file will be used by the Openbravo installer to install the Pack -it means, all its modules- in a clean environment.
test the installation of the new Pack in a clean environment to check it installs and works fine.
update the Openbravo Central Repository of Packs and optionally upload the installation file of the new Pack to Openbravo AppExchange to allow distribution through this channel.

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:

install a Pack in a development environment.
activate the Pack for development.
install/uninstall modules as needed.
edit the list of modules, packs and industry templates included in the Pack from the ones installed in the development environment.
update the major version of the module.
export the Pack.
update the Openbravo Central Repository of Packs and optionally upload the new installation file of the module to Openbravo AppExchange.

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:

install any number of modules, packs and industry templates in their development environment
do any required change in the Application Dictionary to fit the Industry requirements.
register an Industry Template in Openbravo Application Dictionary
define the version for the new Industry Template
define the Industry Template license as a compatible one with the licenses of all modules/packs/templates it includes. Openbravo UI will help on that task.
export to a file the Industry template definition trough an utility in Openbravo platform. All modules installed in the development environment will be included in the industry template as well as the configuration script for all the changes done in the Application Dictionary.
test the installation of the new Industry Template in a clean environment to check it installs and works fine.
update the Openbravo Central Repository of Industry Templates and optionally upload the installation file of the new Industry Template to Openbravo AppExchange to allow distribution through this channel.

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:

install an Industry Template in a development environment.
activate the Industry Template for development.
install/uninstall other modules/packs/Industry Templates as required.
perform bug fixes or other changes in Application Dictionary.
test that those fixes work fine.
update the major/minor version of the Industry Template.
export the Industry Template.
update the Openbravo Central Repository of Industry Templates and optionally upload the new installation file of the module to Openbravo AppExchange.

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

Customizations

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:

users can browse the Openbravo Application Exchange to find and download a module, pack or industry template installation file.
users can get a module/pack/industry template installation file by other means.
they can install into their instances the module/pack/industry template though a friendly UI installer. The installer will take care of dependencies (modules and versions) required for the module, pack or industry template. If the dependencies are not satisfied by the instance the user gets a warning and the installation is cancelled.
as stated previously reference data in a module could be defined for System, Client or Organization. When defined for System that data will be deployed at module installation time. When defined for Client that data will be stored to be used at Initial Client Setup time. When defined for Organization that data will be stored to be used at Organization Setup (to be defined).
users can also uninstall any module/pack/industry template installed in their instances. If the uninstalled module holds information (tables and columns) the user will get a warning that information could be lost. If there are other installed modules that depend on it the user will get a warning explaining that those other modules (and the ones that depend on them, and so forth) will be uninstalled too.
when a module releases a new patch or a new version, all Openbravo instances that have installed that module are notified
users can apply a module patch to their Openbravo instances. A patch should not change dependencies and the process of applying that patch is straigth forward.
users can apply an update to a module installed in their Openbravo instances. Since the update usually will change module dependencies these dependencies are compromised. The installer will take care of that with the following actions:
- when updating a module that other modules depend on it (eg. updating core and there is an installed module that depend on it) the installer will try to automatically get updater to the highest version of those modules compatible with it. If an upgrader is found for all of them the installer will ask to the user for confirmation to update all this modules. If there is not an upgrader available for any of them the installer will ask to the user for a cancellation of the process (recommended) or for performing a partial update (it is required to allow a partial update to avoid locks for instances that have installed a module with poor or no maintenance). Other possibility is to uninstall that module (the user could loose information) or to "promote" that module as a customization.
- when updating a module that depends on other modules (eg. updating a module that depends on core) the installer will check if dependencies are satisfied. If not it will prompt to the user all the "high level modules" that require to be updated before applying that update and will cancel the update process. The rational is that it makes no sense to update a high level module because of it is not compatible with a low level one, but the other way around.
- other aspect that the installer will take care of is code promotions: if some functionality that stores user data has been promoted from one module to other the installer will automatically migrate that information during the update process if the module that receives the functionality is also installed. If it is not the installer will prompt the user for installing this module or loosing that information.

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.

Development

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.

Installation

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.

Upgrading

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

Collaterals

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

ICI: it seems that the configuration script should also manage reference data: it is quite common that a industry vertical requires to modify the document types and other refence data in the client. How to manage this?

Closed Discussion Items

ICI: modules are not allowed to modify components owned by other modules. It highly simplifies the model and makes it easier to test and validate. Rationale behind is: each module is responsible of the behaviour of the components defined by itself. Only an Industry Template, with full visibility of the whole installed system is allowed through configuration script to modify those components.

PJU: In a pure self-service model - required for a full support of a pure multi-tenant system - the user should be able to initiate the creation of a new client using a template without having any previous access to the system. This action would then be considered as a request and it would need to go through a workflow which includes various steps (example: payment collection, approval, provisioning, etc.). This presupposes the existence of a workflow engine, which is not available in Openbravo. Instead, we assume that the user can connect with a guest user and initiate the action. Is this acceptable?
- ICI: Self-service model as expressed is related to multi-tenancy and SaaS operation and not to modularity. This feature will be considered in the future as a web service for the Initial Client Setup but not within this project.

PJU: Larger enterprises can have multiple organizations each implementing different lines of businesses or operations in different countries. It is therefore conceivable that a larger organization might want to implement different industry templates within a single client. The current proposal is to have a template per client. Is that acceptable? This feature targets smaller enterprises that typically have only one organization; is that a reasonable simplification assumption?

- ICI: Current proposal is to allow templates with maximum granularity supported by OB platform: AD components/SW resources defined per System, and reference data defined per System, Client or organization. As stated in the scope section this project is limited by platform capabilities and it does not go beyond them.

PJU: Should an industry template include window configurations as well (field names, layouts, etc.)?
- ICI: same as previous point. Current OB platform does not support AD components defined per client. The implication of this decision is that - with the current version of Openbravo - all the clients in a hosted system must share the AD definition although they can have different reference data.

ICI: core is a module, or not? If so, should we separate it from platform (application dictionary)? -> Core -including platform- is one module and won't be broken into smaller modules. It could be a project for next releases.

ICI: objective is that any customization can be easily shared as a module. To make it easier naming convention -including uniqueness of module name- should be guaranteed from the very beginning. It forces to register/validate any custom module before starting any development, does it make sense? -> Yes, it makes. The Central Repository will take care of this.

ICI: How to manage module information when it is applicable client by client or organization by organization: initial client setup? organization setup? -> Yes, client and organization information can be loaded from modules using Initial Client Setup -to be modified in this project- and Initial Organization Setup -to be created in this project-.

ICI: Is the Industry Template concept necessary? Why and How it is different from Verticalization Pack? The only difference is that Industry Templates are allowed to hold configuration scripts... -> But this difference is huge: an Industry Template is owner of the whole fuctionality included in the Template and this is the reason to allow them to modify module content through configuration scripts.

ICI: should it be possible to define incompatible modules? Eg. modules that provide the same or similar functionality; or just because name collisions... -> No, there is no need to define incompatible modules. Technically all modules should be compatible between them. Perhaps the functionality from two different modules is incompatible (eg. because both try to add the same functinality) but both modules can be installed together without any error.

ICI: should the system allow to install just one Industry Template? Does in happen in other modules/packs? -> Yes, the Module Manager Console will check that just one Industry Template has been installed in the instance. It does not apply to modules and packs, the user is allow to install as much as needed.

ICI: should modules support optional content (content that the user decides at installation time if it is included)? -> No, all the content in a module is mandatory.

ICI: how to manage demo-data for modules? It will be hard to get data integrity. -> Demo data for modules is out of scope in this project.

ICI: should we allow overwritting on SW resources? Currently it happens in standard customizations with document reports. -> Overwrite files won't be allowed in standard modules. But the migration tool will support that behaviour to help old instances to be migrated to modularity. The customization module from those instances will be marked as dirty and should not be shared with other instances.

ICI: should reference data be uninstalled? It is really difficult and risky to implement. -> No, reference data can not be unisntalled but inactivated.

ALO: Configuration Script by description is only able to modify application dictionary components, thus it cannot modify physical database structure. This means a modification in the existent structure cannot be expressed as a template, and some kind of structure changes are prone to be in customizations. For example a customer would want to make a name column higher. -> A configuration script IS able to modify physical database structure.

ICI: define rules to ensure that all modules are compatible between them so there is no need to keep track of "uncompatible modules" for a given module. For instance, a module is not allowed to add a mandatory and not defaulted column in a table that is not owned by the module to avoid other module including reference data without that column info that will fail when loading. -> This rules will be first written down in the Module Developer's guide. At a later stage can be validated when packaging a module.

EAR: is it allowed to uninstall reference data from modules applied to System, Client or Organization level? It is risky because there could be transactional data refering to them. What happen if a reference data loads a record and in the next version that record is not included (so it was removed from the reference data set). Should the system try to delete it from the instance? It is risky... Perhaps the best approach is to force to keep that record in the reference data set but disabled. -> As stated previously reference data is not removed from the instance when the module is uninstalled nor when the those records are removed from the module source.

ICI: is there optional content within a module to be choosen at installation time? could be a module in a pack or industry template optional? -> No, there is no optional content. Just for reference data at Client/Organization level the user is allowed to choose what modules to apply.

ICI: should modularity (Central Repository) provide security mechanisms to avoid that people distribute not open source modules within a pack or industry template? -> No, this type of features are out of scope

ICI: two versions of the same module can not be present at the same time in a Openbravo instance (because of collision of names). So to maintain different versions of the same module it is required to have different ob instances.

ICI: at installation time there is no client/organization setup, so there is no way from the Module manager console to apply reference data to existing Clients/Organizations

Projects/Modularity/Specifications

Contents

Openbravo Modules , Packs and Industry Templates - Functionals Specifications

Overview

Purpose

Scope

References

Design Considerations

Assumptions

Dependencies

Constraints

Glossary

Functional Requirements

User roles & profiles

Concepts

Module

Application Dictionary Components

Software Resources

Reference Data

Pack

Industry template

Configuration script

Central Repository

Naming and packaging rules

Customization

What can and cannot be done

Change the invoice report clicking the toolbar print button

What cannot be done

How to do

Contents

Tax Payment Functionality

How to do

Contents

Rapid order line insertion

What cannot be done

How to do

Contents

Import Taxes Process extension

What cannot be done

How to do

Invoice post modification

What cannot be done

How to do

More examples about what cannot be done

A Complete Example

The Scenario

Openbravo ERP Implementation

The Industry Template

Reference Data

Modules

Financial Institution Connector

Paypal Connector

Business process definition

Development and maintenance of Modules

Localization/Verticalization Packs development and maintenance

Industry Templates development and maintenance

Customizations

Installing, uninstalling and updating modules, packs and Industry Templates

User stories

Development

Installation

Module promotion and maintenance

Upgrading

Functional requirements based on business processes

Development of Modules

Module Manager Console

Load module reference data at Client/Organization level

Collaterals

User Interface Mockups

Module development

Technical Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

Navigation menu

Search