1. Business Applications
Introduction to Business applications
The complexity of an ERP is usually due to the high number of available features. Most of the users
of the system uses only a few features, according to their job position(s) in the company. In order to
remain easy to use, the different features are splitted into business applications.
The main idea is that a user is often working in a particular context (working on a project, recording
accounting entries). When he is in such a context, he should directly see all features related to this
context (=business application). We try to create business applications according to user's position
in the company: salesman, project user, purchasers, accountant, etc.
Notes : OpenERP makes the difference between modules and applications. A module is a set of
features packaged together for technical reasons. A business application includes all the features
coming from different modules and creates a menu structure according to a specific role in the
company. An application is usually composed by a set of modules.
These business applications define a context of work and every therminology used in an application
must be relative to this context, so that it's easier to understand : a purchaseman will see adapted
screens to purchasing operations. An accountant may see the same data, but in an accounting
context. (adapted therminology, adapted menus, adapted default values in each screen)
As an example, a purchaseman will see the following menu on the left:
• Purchases
◦ Request for Quotations
◦ Purchase Orders
• Address Book
◦ Suppliers
• Invoice Control
◦ Supplier Invoices to Receive
• Inventory Control
◦ Incoming Shipments
The menu related to the application is always visible on the left of the screen and the applications
are displayed in the red top menubar.

2. Business Application means that one responsible user could stay in only one menu to achieve his
work.
Several menus may refer to the same view (with adapted default values) because they are used by
several applications. As an example, a warehouse manager should see the following menus:
• Warehouse Management
◦ Incoming Shipments
◦ Internal Moves
◦ Delivery Orders
In that example, Incoming Shipments is available in the “warehouse management” application and
in the “purchase management” application. The menu Suppliers is also referred as Partners in the
“Accounting” application, but partners includes Suppliers & Customers. So, the terminology is
adapted to each application.
Guide lines
Defining new applications or completing existing ones
We usually try to define new business applications related to job positions in the enterprise. As an
example, these are good examples of applications : Purchase, Sales, Accounting, Project, etc. Don't
create business application by features. These are wrong examples of business applications : lunch
orders management, expenses sheets, etc.
If you have specific features that do not belong the existing business applications, you can put them
in the “Miscelleanous Tools” application.
Configuration wizards of business application.
Each application must create an entry in the main base_setup wizard that shows all the possible
business applications defined in quality certified modules only.

3. You can also create one configuration wizard dedicated to your business application. Example,
when you install the project management, you get this wizard:
Business Applications must be complete
One user/role must be able to perform most of his tasks from one business application. He should
not be forced to swtich to another application to perform the tasks of the same role. Example, a
salesman should see in his menu: Leads, Opportunities, Meetings, Sales Orders, Sales to Invoice,
etc. He should not be forced to go to the accounting application to invoice the sales.

4. Transveral features, used by all applications
Some features should be accessible by all users, not depending on the application they usually
works in. As an example, most of the users should have an access to: Partners, Agenda of Meetings,
Products. In that case, you put the menu in the applications that needs these features more.
(Example: the address book is in the sales, purchases and accounting application)
And, these features must be set as shortcuts for every user in the system by default, at the creation
of the user.
Access Rights must define groups per application.
The groups defined by each module must be directly related to business application. So, if you have
an application which is “Accounting”. All groups within this application must be like: “Accounting
/ Accountant”, “Accounting / Financial Manager”, etc.
The first menu is the most used one
The first menu of a business application is unfolded by default. Put in this menu the most important
features, usually those that correspond to daily operations. As an example, for a salesman, the first
menu of the “Sales” application contains: Leads, Opportunities, Quotations and Sales Orders.
One dashboard defined per application
Each business application must have one dashboard attached to his root menuitem. When a user
enters in a business application, he should see the dashboard related to this application.
Configuration Wizards
Configuration wizards are launched automatically at the creation of a new database. You must
develop configuration wizards per application in order to:
1. Help the user choose the features (=modules) he wants to install or not
2. Help the user to configure the system
For the point (1), the less the user install modules, the easier it is to understand the system. So, most
of the features are proposed as extra in the configuration wizards.
For the point (2), whenever it's possible, it's better to provide a default configuration that works for
most companies as data created by default instead of developing a configuration wizard to ask
questions to configure the system.
Don't forget that configuration wizards are here to help users to configure the system tailored to
their need, not to ask complex questions for very specific configurations.
OpenERP allows user configure his OpenERP following his business's needs. When user creates a
database, he can choose one or more application(s). Following application(s) chosen, he can see
some configuration wizards to add modules related his chosen application(s) and so, his needs.
Example : user has chosen “Project”. He will have another wizard to configure Project
Management.

5. Guide Lines
A common layout for all wizards
• Adapted title to each application : as introduced, chosen application leads to one
configuration wizard. Then the configuration wizard has to have a title related to the
application.
• Picture and information on the left : all wizards have to have one business picture and an
explanation text regarding the business application to configure.
• Objects (Documents) to configure on the right : all objects related to the application must
be chosen with selection box. And have to be placed on the right
• Allow user to Skip or Configure : each wizard has to have 2 buttons, one to Skip and one
to configure. These buttons have to be placed below on the right.
• Progress bar : to allow user see where he is in configuration, all wizards have to have a
progress bar with the percentage of completion of database.
• Separators : Each parts of the wizard has to be separated by a separator bar

6. Configuration wizards are optionnal
Configuration wizards are optionnal. The system must be useable and configured by default even if
the adminsitrator skips all steps during the configuration process. Configuration wizards are
available only to:
1. Propose new features to install (a set of modules)
2. Change the default configuration of the system (and not configure the system !)
Configuration wizards are part of the applications
Most of the application wizards must be part of one application. Be sure that:
• The application this configuration wizard belongs to is explicit
• Therminology are dedicated to the application context
As an example, in a project management application, don't talk about analytic account or entries but
talk about projects and timesheets. Avoid configuration wizards that are transversal to several
applications.
Configuration wizards and extended/simplified views
Be sure you use extended/simplified views features also in configuration wizards. In order to
simplify the confguration process, some options or wizards must be available in extended views
only.