View source | Discuss this page | Page history | Printable version   

ERP 2.50:Functional Documentation/General Setup/zh




这一章节介绍如何建立一个能运转的数据模型,你能看到系统内设置很多,但是如何正确的顺序来做,我会介绍给你。首先,你应该有一个已经安装好的Openbravo了,如果没有,去安装后,再来看这个。使用OB(openbrave)要按照下列顺序。 (图片简单翻译如下,请对照看。) 客户初始化设置——导入数据——生产设置——业务伙伴设置——会计设置——通用设置——应用、客户=实体、安全、组织机构。

General Setup.png

本章致力于通用设置。This module improves and increases the performance of OB and allows to setup multiple things.



Openbravo 是个多公司系统.每个客户-实体都被作为一个公司管理。这种管理是各自独立的,每个实体互不相干。 每个实体包括一个或多个组织机构。(实体是集团公司,组织机构是分公司) Openbravo 正常运行至少会有两个实体。一个管理模型数据和原始数据(系统实体),另一个管理实例/交易数据(你建立的公司实体)。



  1. 1号实体是系统实体。想看这个实体的所有数据都必须用系统管理员的身份登录。初始的系统管理员:Openbravo 密码:openbravo。(请注意大小写) 这个实体有所有的模型数据,包括表、列、窗体、区域、菜单等等。其他实体虽然各自独立,但是它们使用同样的窗体、区域,这些都设置就在这个系统实体。同样,各个实体都需要用到的公共原始数据、通用数据也在这个系统实体内。
  2. 这个新客户-实体是必须用 客户初始化设置 才能建立的。所有的用户的交易数据都在这个实体中,只有隶属于这个实体的用户才能访问这些数据。

Create a client/建立新客户-实体

要建立一个新客户-实体只有一个办法,那就是使用 Initial client setup/客户初始化设置。因为这个建立客户-实体的过程需要进行大量的后台操作,所以不提供第二种方式,以避免错误发生。

具体步骤请看 建立新客户-实体.


Client set up.png

These four tasks are independent so if one of them fails, the process keeps going. But the fact is if data client or financial data fails OB won't work correctly.

1. Data client

This task is in charge of:

As an example and filling the fields in the Initial client setup window as this way:

The process creates:

And relates the users → roles → organization having at the end this structure:


The reason why the process relates the new roles with user Openbravo is because Openbravo is the super user of the application so that user can manage all the entities and the application dictionary.

The difference between Sirof and Amedio users comes from the roles so with the organizations as well. Having access to organization * means that you can see everything in the application independently from the organization. However having access only to organization Pamplona means that you can only see the data related to this organization.

2. Accounting data

This task is in charge of:

This task can be avoided if the chart of accounts is not selected. This has sense when OB is not used for accounting purposes just for management.

3. Financial data

This task is in charge of:

From 2.50 MP19 version onwards, this is an optional step. In the initial client setup window, a new dataset is created belonging to core, with all the information about document types, sequences, etc., so core will appear as a module to be applied. If chosen, then all this data will be created for the new Client. If not, nothing will be created, and user will be able to apply this dataset later on through Enterprise Module Management window.

4. Master data

This task is in charge of:

Client information

Going to General setup → Application → Client → Client other things that can be configured:



An organization is a business unit within an entity. Each entity can have more than one business unit, to reflect different departments or divisions of the parent entity. Organizations can be structured geographically, by region or by function. Every organization is managed independently, but it is possible to share information between them for example business partners and products.

Organizations are set up using a tree structure so an organization can have access to specific documents and those of the child organization but not to documents of the sibiling or parent organizations.

All the organizations always depends on the super organization called '*', which is created automatically during the Initial Client Setup process. A hypothetical tree could be:


Organizations can be independent of each other in terms of account structures, and reporting, but every organization has the following characteristics:

Organization Types

Organization types enable organizations to work together in a coherent way, by controlling how each organization behaves in relation to other organizations. There are four default organization types, which are sufficient for most business scenarios.

The default organization types have the following characteristics:

Organization Type Legal Entity Legal Entity with Accounting Business Unit Transactions Allowed
Organization N N N N
Legal with accounting Y Y N Y
Legal without accounting Y N N Y
Generic N N N Y

Period Control

If an organization belongs to an organization type where the Legal Entity option is selected, you can specify whether that organization is or is not allowed to open or close its own accounting periods. If period control is enabled for an organization, any user with access to that organization can open and close an accounting period.

When opening a period, the user can opt to also open the selected period(s) for child organizations. However, when closing a period, the selected period is closed for all dependent organizations.

If an organization has multiple accounting schemas, the opened / closed period will also be opened / closed in all associated schemas.


It is not mandatory that each organization has a financial calendar, but where an organization is a Legal Entity, any sub-organizations that require financial calendars must use the same calendar as the parent organization.


You can restrict reports so that they can only be generated for organizations whose organization types have the Business Unit or Legal Entity option selected. In Financial Management > Accounting > Analysis Tools > User Defined Accounting Report Setup if the Balanced option is selected, the Organization field displays only those organizations with a Business Unit or Legal Entity status.

Organization Type Parameters

For most enterprises, the default organization types are enough to enable you to model your organization. However, understanding the underlying settings of organization types will help you decide which organization types you require. Some enterprises may also need to create custom organization types.

In General Setup > Enterprise > Organization Type, there are four options that govern how organizations of each organization type behave.

Legal entity

If an organization type has the Legal Entity option selected:

Legal Entity with accounting

If an organization type includes the With Accounting option:

Transactions allowed

If an organization type includes the Transactions Allowed option, organizations belonging to the organization type are allowed to post transactions for accounting purposes. If an organization is of a type where transactions are not allowed, you cannot include that organization on an accounting document, for example an invoice.

Business Unit

If an organization type includes the Business Unit option:

Organization type rules

If your enterprise has more than one organization, you must observe the following rules when setting up the organizational structure:

It is recommended that you enable period controls on all organizations of legal entity with accounting and assign each legal entity organization its own calendar


The security permissions in a multi-organization follow this schema:


  1. Allowed to create documents in any organization except Org *
  2. Allowed to see data related to any organization
  3. Allowed to create any master data in any organization including Org *
  4. Allowed to create documents in Main org and Org1
  5. Allowed to see data related to Main org and its child organizations (org1, org2). Also the possibility of only selecting the Org1
  6. Allowed to create any master data in any organization except in Org2
  7. Only allowed to create documents in Org2
  8. Only allowed to see the data related to Org2
  9. Only allowed to create master data in Org2 including Org *

See also Setting up an organization section of the Configuration Manual.

Organization information

In this tab there are two very important fields that needs to be well configured:

The calculation of taxes depends on this because when a tax is configured there are four fields that must be correctly setup: Country from/Country to, Region from/Region to.

So in a procurement flow, OB takes the Country from and the Region from from the supplier location and the Country to and Region to from the Organization location.

In a sales flow, is the other way around.

This business partner is used for internal processes that needs a business partner. For example in internal transfers. Doing internal transfers (i.e from the cash journal to the bank account) means create two bills (one payment, one receivable) so a business partner is mandatory for this.

Not having this business partner setup the process Financial management → Receivables&Payables → Transactions → Funds transfers won't work.


The purpose of this section is to explain the current model for Openbravo security.

Security can be divided into functional and data. Functional Security defines access to different application elements while Data Security determines which data inside those elements is accessible or not.

Functional security

Vertical security manages the definition of users, roles and permissions adding users to roles and making possible to decide if a user can access to a determinate element (for example to a window, form, process)

So the issues involve in vertical security are:


Users are the entities that can log into the application. The minimum requirements for a user to be able to log in is to have a password and at least one role associated. A user is supposed to be a representation of a person (each person should be a different user)


Roles are the connection between users and permissions, permissions are associated to roles and roles are linked to users. A role defines what information is allowed and which is forbidden. Despite of the fact that a single user can have multiple associated roles, only one role is effective at the same time: although the logged user has more than one role she or he will have to select one role or another one in order to have different access permissions.


Different permissions can be associated to a role. The effect of this is that the role will have access only to those elements having permission to.

Permissions are defined in the following levels: Organization Access, Element Access (windows, forms, processes...) and Table Access.


Data security

Horizontal Security is managed by clients, organizations, access level and user level. Thus is decided which data is accessible and which is not.

Data access level

Access level defines from which client/organizations is data visible. Access level is set for tables, processes, forms, workflows and tasks, so any of this elements has one access level. There are five possible levels:

The access permissions for them is described in the table below, where:

Client Org Description
System 0 * Only allow to see records with client 0 and Org *. For example the application dictionary records
System/client Non 0 * Only allow to see records in any client except 0 and see Org *. For example master data records
Organization Non 0 Non * Only allow to see records in any client except 0 and see any org except *. For example transactional documents
Client/Organization Non 0 Any Only allow to see records in any client except 0 and see any org. For example transactional documents, master data

All Any Any Allow to see anything

User level

Every role has a user level which is used in the vertical security way in order to allow or deny access not only to data but to the whole element (for example to a window). There are three possible user levels (and their combinations): Client, Organization and System. User level is used in conjunction with Data Access level, so only roles defined with a type of user level can access to some types of elements defined in some Data Access level, it's summarized in the table below:

Data Access Level User Level
System System
System/Client System or Client
Organization Organization
Client/Organization Client or Organization
All System, Client or Organization

Log in security

Bulbgraph.png   This feature is available from 2.50MP15

Log in security includes 2 features: User/Password check time delay after failed log in and Locking Users.

These 2 features are intended to prevent bots doing Brute force attacks to find out a user/password.

Both of them are configurable using the file. Note that is read for this purpose from sources directory, so it is not necessary to deploy the application nor restart Tomcat if they are changed.

User/Password check time delay

A time delay can be included for the log in user/password check after an invalid log in attempt. This delay is applied for a user in case the last time he/she tried to log in the application did not enter a valid password. This delay makes bots to spend much more time trying to guess a password for a user, making them virtually unusable.

The delay increments each time the user fails up to a maximum time. Once there is a correct log in for that user, the delay is reset and it will be applied again in case of new fails.

It is configured through 2 properties in file.

Locking Users

Users can be locked after a number of failed log in trials. Once a user is locked he/she cannot log in the application until the user is unlocked. A message informing about this situation will be displayed.

The number of trails before the user is locked is configured by the login.trial.user.lock property. If it is not present, empty or 0, users will not be locked and locked users will have access to the application again. It is defaulted to 0.

Unlocking Locked Users

When a user is locked, it can be unlocked by an admin user. To do so log in as admin and go to General Setup || Security || User window. There uncheck the Locked field.

If admin is locked, it will be necessary to (temporary) disable the user locking mechanism by setting login.trial.user.lock property to 0 to allow access. Once the admin has logged in the application, this property can be restored to the previous value. Now you can proceed to unlock the user as explained in the paragraph above.

Setup background process

Any background process can be defined in OpenbravoERP. This processes can be developed as a PL or java file and they can be scheduled and automatically executed. Processes can be executed at whatever interval is required, daily or on the specific days of the week, as a recurrent event or a one-off at a particular time.

The steps to create and setup a process are:

Also the background processes can be activated or deactivated and this is very useful because sometimes when the process can run manually first is mandatory to stop the background process (i.e:PeriodicAcctServer)

Setup languages

OpenbravoERP is a multilingual application which means it is possible to see the whole interface in different languages.

See the steps for import/export translations.

In Openbravo database exist some tables that have their own translation table. All these kind of tables must be filled in English and the translation ones in the language that user wants. Whenever you login in English you see the data from the original tables, but if you login in a different language you will see the data from the translation tables.

See the relation of the translations and tables.

Initially (from the installer) the translation tables comes in Spanish as a default language so means all the tables have their translation in Spanish.

The way to import/export translation work is:

Import export.png

Setup default values

In OpenbravoERP there are three ways of setting default values:

Whenever a user logs in, the application establish some session variables and within these are the default values. These all default values are managed in a hierarchy way.

Example 1:

A default value is set in Financial management->Accounting->Set up->Document type marking the record "POS Order"

Now as you are still logged in, if you go to the Sales order window and click New it won't show up the value "POS Order", but logging out and then logging in, the application will establish the new session variables and the "POS Order" value will show up

Example 2:

Maintaining the default value from example 1, the user may decide to set up another default value through the application dictionary in the same table as the window "Sales order" uses.

In this case the user must go to Application dictionary->Tables and columns-> and select the table C_Order. Then select the column C_Doctypetarget_id and fill the field "Default value" writing the ID for the corresponding document type. Let´s write for this example "Warehouse order".

This set up will have effect after the application is compiled

So now for the same window the OpenbravoERP has two default values, POS order and Warehouse Order, but this won't be a problem as the default values work in a hierarchy way.

The default value for the window will be "Warehouse order".

Example 3:

Finally the user decides to set up a new default value for the window "Sales order", but, in this case, using the preferences method.

The user should go to General set up->Application->Preferences and select the window, write C_Doctypetarget_id in the attribute field and the ID of the corresponding document type (e.g. Standard Order)

As before, only by logging out and logging in again will the new default value be established permanently.

So at this point OpenbravoERP will have three default values:

But the definitive default value will be "Standard Order" because the preferences method is the most restrictive way of setting up default values

Setup alerts

Alerts are the way Openbravo ERP informs users about virtually any event that happens in the system and the administrator has defined a rule to show it.

The work flow for alerts is as follows:

For more information click here

Setup Menu

The way of configuring the menu in OpenbravoERP is easy and simple. The menu is organized in a hierarchy way as a tree node.

There can be two types of nodes:

To add these actions in the menu and working:

  1. Create the element through the application dictionary: Windows, Reports, Process, etc.
  2. Compile the window, process, etc.
  3. Create node into the menu and add the action
  4. Finally move the node within the menu


When a node group different nodes, no actions can be related. For example when you create a new module or different sections inside a module (i.e. Reports, Set up)

See how to change the order in the menu.


Bulbgraph.png   The contents of this section are applicable from 2.50MP18

Preferences can be manually set from General Setup || Application || Preference window. They can also be populated by modules.

The list of principal preferences defined in core is:

Upgrade from a previous MP

Preferences are loaded in session when logging in the application or changing the current role. The way they are loaded has slightly changed in 2.50MP16.

Because of this change, When upgrading core from a version prior to 2.50MP16, depending the preferences defined in the instance, it is possible some changes in the behavior. These cases are detected during the upgrade process displaying a warning. Administrator should take care of these cases. Note that this warning only appears during the upgrade process from a version prior to 2.50MP16 to 2.50MP16 or higher, but it will not appear again.

Retrieved from ""

This page has been accessed 11,107 times. This page was last modified on 3 April 2012, at 11:00. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.