Projects:EnhancedMulti-organizationSupport/Specifications-tmp
Enhanced Multi-organization Support - Functional Specifications
Overview
Purpose
The purpose of this project is to define the behavior of Organizations within Openbravo ERP. Openbravo ERP is a multi-client and multi-organization application, but some functionality about multi-organization is not coherently managed.
This project studies where organizations are used and defines the rules that processes which manage organizations must follow. It also studies how to define data that can be redefined for several organizations in a hierarchical way, for example, for the main organization there may be a custom description of the product but at other levels of the hierarchy of organizations the custom description is different.
Scope
The scope of this project is limited to the process described in this document. Particularly, the data that can be redefined are the specifically designed in the configuration of the installation.
Design Considerations
The multi-organization support is a feature of the system core. So currently, all registers have an Organization field to identify the organization that owns the register. For some functionalities, like accounting and warehouse management, there is need to define specific rules.
For the purpose of define different data at different levels of the hierarchy of organizations, we have addressed the goal to allow to define new information that can be redefined by the organizations. This does not include changing referential data that can change the behavior of other processes. For this purpose is necessary to design the process to support different data for different organizations like in the case of the MRP with data specifically for each organization (see Product Configuration).
Assumptions
- All organizations are going to be managed within the same client.
- The client is going to use different organizations.
- The organizations can be legal entities, business units or any subdivision of a legal entity or business unit that has sense for the company.
- A document is only of one business unit or legal entity, so it only generates accounting entry in their business unit. This imply that all the lines of the document are of this business unit and all the entries are of the same business unit. If the user don't want this restriction, he can consider the organizations as cost centers (they aren't legal entities nor business units).
Dependencies
None.
Constraints
See Design Considerations.
Glossary
- Client: the container of organizations that does not have any relation with other clients.
- Organization: any logical or physical subdivision of a company or a group of companies. A user can be granted to access some organizations but not others.
- Legal entity: an organization which is a legal corporation.
- Business unit: an organization with its independent accounts. It belongs, with other business units, to a legal entity.
- Cost center: it is a organization, part of a business unit or legal entity, that can be assigned with incomes and fees, to obtain its Profit & Loss report. They usually have a Profit & Loss budget.
- Accounting schema: the rules that define how the accounting is done. These rules include the chart of accounts.
Functional Requirements
User roles & profiles
The target users for this project are:
- Administrators: these users have a good knowledge of Openbravo ERP and they are in charge of defining the roles and permissions of the users.
- Users: common users of the application.
Business process definition
This project is related to all processes related with transactions. The processes that define master data only include the organization as a field.
User stories
Story 1: Role definition
- Carl Hughes, the administrator of the application, wants to grant Paul Garrison access to invoices in organization A1 and access to shipments in organization A2.
- To do so, he logs in as System Administrator and creates a role with the specified permissions. Then, he adds this role to user Paul Garrison.
Story 2: User access
- When Paul Garrison logs in the application, he sees the menu with the entries he can access to. When he changes the default organization, the menu changes to show the new entries he has access to.
Story 3: Specific data values
- In organization A1, Paul Garrison wants to have a different description of some products. For that reason, a new auxiliary field has been defined in Openbravo ERP's configuration: custom description. This field has a default value in the main organization but it can be changed at any level in the different organizations. The new value overrides downward the previous value.
Story 4: Accounting
- The Soft Drink Co is a company with different business units (Cola Drink, Orangeade, Soda), each one has a north delegation and a south delegation. As they are different business unit, there is need to define both delegations for each business unit, so we have six delegations: Cola Drink North Delegation, Cola Drink South Delegation, Orangeade North Delegation, Orangeade South Delegation, Soda North Delegation, Soda South Delegation.
- Soft Drink Co manages all these business units with an installation of Openbravo ERP.
- Each element must be defined as an organization: Soft Drink Co, Cola Drink, Orangeade, Soda, and the six delegations. These delegations can be considered as Cost Centers.
- Soft Drink Co must be marked as a legal entity.
- Cola Drink, Orangeade and Soda must be marked as business unit.
- The delegations mustn't be marked as legal entity or business unit. Any organization can be managed as a Cost Center without aditional definitions.
- Cola Drink North Delegation can't do an invoice with products of Cola Drink North Delegation and Orangeade North Delegation, because they own to different organizations; the application must check that this can't happen. If the Cola Drink North Delegation wants to sell products of Orangeade North Delegation, first it needs to buy them to Orangeade North Delegation with a shipment and an invoice (internal invoice) of shipment and purchase. After this purchase, the orangeade is a product of Cola Drink North Delegation that it can sell.
- If the user wants to create invoices with products of Cola Drink and Orangeada, he mustn't define the organizations Cola Drink, Orangeade, Soda as business units, and then are managed as Cost Centers.
- The user wants to have some account reports (Balance sheet and Cash Flow Statement) for each business unit. In the configuration he must define which reports can be get for business unit. In this way, he can't get a Balance sheet for a Cost Center (it would be unbalanced). The Profit & Loss report can be obtained for any organization as it isn't check as a report for business units.
- A user of Soda organization wants to obtain the account reports for the Soda business unit with a specific chart of accounts additionally to the chart of accounts defined for the legal entity. The user needs to obtain the account reports for the whole company with the same accounting scheme.
Story 5: Document organization
- A user of Cola Drink want to make a remittance with payments of Cola Drink North Delegation and Cola Drink South Delegation. He's allowed to do it because they are of the same business unit. The new remittance has a header and two lines. All the document owns to Cola Drink, although the lines contain payments that are of the delegations.
Story 6: Period control
- The administrator of Soft Drink Co wants to allow to Cola drink and Orangeade business units to open and close their accounting but not to Soda, as its accounting is managed by the central.
- An user of Orangeade wants to create an invoice for the past month, but he isn't allowed to do it because the period is not opened.
- The business unit of cola drink has made all the month's documents and wants to close the period. Other organizations (orangeade, soda) are still working in that period. Cola drink business unit can close the period without affecting the other organizations. Next week, the central organization is going to close the period. This closing applies to all the business units. If the central organization reopens the period, cola drink business unit will not be able to enter operations because its organization remains closed.
Story 7: Organization specific data
- Soft Drink Co defines the field "Description" of the product as organization specific data. Soft Drink Co creates a new record with the value "New bottle xxx" for description.
- All organizations see this description. Cola Drink updates the description to "New bottle yyy". Now the Cola Drink North Delegation and Cola Drink South Delegation see the description "New bottle yyy".
- Cola Drink North Delegation updates the description to "New bottle zzz". This is the only delegation that sees this description.
- After these changes, Soft Drink Co updates the description to the value "New bottle xbb". These change applies to Orangeade, Soda and its delegations, because they haven't changed the original value. Cola Drink and Cola Drink South Delegation continue seeing "New bottle yyy" and Cola Drink North Delegation continues seeing the description "New bottle zzz".
- Now, Soft Drink Co wants to redefine the description for all the organizations. The user has to go to an specific window where he defines how the new value updates the previous ones. These window can have a graphical design showing the relations in the definition of the values; this window has to take in account the permissions of the organization.
- Now Soda creates a product with the field description of "Fresh Soda aaa". This description is copied to all the organizations, including the parent ones.
- After the creation by Soda, Soft Drink Co updates the description to the value "Fresh Soda bbb". This change applies to Cola Drink, Orangeade and its delegations, because they haven't changed the original value, but not to Soda and its delegations.
- Now, Soda, the owner of the record, changes the description to "Fresh Soda ccc". This change applies to Soda and its delegations, but not to Soft Drink Co, Cola, Orangeade and his delegations.
- In this case, we want allow the owner of the record to edit the field (because it is a technical field). He can overwrite the value of Soft Drink and the other organizatios using the specific window. This specific window shows a tree with the values in each organization.
- Instead, in other organization specific field, as price, the administrator doesn't want allow the owner to overwrite the value defined for a parent organization. For this, each organization specific field has a check to define if the owner can change the parent data when this data has been changed.
Functional requirements based on business processes
Accounting
| Num | Requirement | Importance | Status |
|---|---|---|---|
| 1.1 | Define specific types of organizations. Each installation can define their own types of organizations. Some of then must be marked as:
Every type of organization must define whether or not it can have transactions. | Must have | To be planned |
| 1.2 |
Each organization must be defined as one of the organization types defined for this installation. Every organization were transactions are possible must have one and only one ancestor (including itself) that is a legal entity. Every organization can have (not compulsory) one and only one ancestor (including itself) that is a business unit. | Nice to have | To be planned |
| 1.3 | Check that a document and therefore an accounting entry do not have elements of different business units or different legal entities. This is necessary to guarantee that the accounting reports are balanced. | Must have | To be planned |
| 1.4 | Include a mark in the reports that only can be obtained by a business unit or a legal entity. These documents are named business unit report. | Should have | To be planned |
| 1.5 | Check that the business unit reports (the reports marked in the previous point) can only be obtained for business units or legal entities. This is necessary to guarantee that these accounting reports are balanced. | Should have | To be planned |
| 1.6 | The lines of a document belong to the same organization that the header of the document. So a document only has one organization. | Should have | To be planned |
| 1.7 | A business unit or a legal entity can have one or serveral schemas attached to it. | Must have | To be planned |
| 1.8 | The organizations that are a legal entity or a business unit or their ancestors can have one or several accounting schemas. An organization that is a legal entity must have itself or an ancestor at least an accounting schema, so it is possible to get the accounting reports of all the legal entities with the same accounting schema. | Must have | To be planned |
| 1.9 | All the organizations that belong to the same legal entity must have a unique calendar. So, an organization that is a legal entity must have assigned itself or an ancestor a calendar that includes years and periods. The control of the periods is a different process described below. | Must have | To be planned |
Period control
| Num | Requirement | Importance | Status |
|---|---|---|---|
| 2.1 | An organization that is checked as business unit or a legal entity has a mark to define if that organization can open and close the period control. | Must have | To be planned |
| 2.2 | The period control must be managed independently of the process of creating calendars and assigning calendars to organizations. A user can have access to close and open a period but not to create calendars, years and periods.
There are two actions related to period control:
The open and close of a period is made selecting the following information:
The open and close of the periods is made for all the defined accounting schemas. The only exception can be for the manual accounting entries (nice to have). | Must have | To be planned |
| 2.3 | The period control includes the ability to create the document. In this way, the control avoids the situation in which the user has created a document (e.g. an invoice) but can not account it because the period is closed.
To be able to complete and account (post) a document two conditions must happen:
If it is not possible to complete or post a document, the system displays which organization avoids processing it. | Must have | To be planned |
| 2.4 | The closing of the year is better to do by accounting schema. | Nice to have | To be planned |
Warehouses
| Num | Requirement | Importance | Status |
|---|---|---|---|
| 3.1 | A warehouse and its storage bins are a business object. A warehouse and its storage bins belong to an organization. Although, it can store material received in movements that belong to different organizations. | Must have | To be planned |
| 3.2 | The owner of the product is the organization that has done the movement. The product may be defined by a different organization and the warehouse may belong to another organization, but the owner of the product is the organization of the movement.
For the material issue, it can be done only for an organization that belongs to the same business unit or legal entity. This assures that the accounting is balanced. | Must have | To be planned |
| 3.3 | To get the inventory of the products of the organization. This can be done by the user that is granted to access this functionality in the organization. The products can be in a warehouse owned by other organization, but he can see them because is the owner of the product. | Must have | To be planned |
| 3.4 | To get the inventory of a physical warehouse. This can be done by the user that is granted to access this functionality in the organization that owns the warehouse. The owner of the warehouse can see all the products independently of the owner of the product. | Should have | To be planned |
Security
| Num | Requirement | Importance | Status |
|---|---|---|---|
| 4.1 | Each security object has two attributes to indicate that the permission to read the security object extends ascendant and descendant. The names of this attributes are:
They are Boolean attributes. The value of the attribute is the default value for permission for a role of the security object. This default value can be modified in the permission. | Nice to have | To be planned |
| 4.2 | Definition of security control for security filters.
In each security object the user can define the fields that are security controls. The fields defined as security controls can be used to define the access security to the register. If the security is based in another field dependent of a field of the security object (e.g. the product category), it is necessary to include this dependent field in the security object although it can be defined as not visible. An exception to this requirement is the organization. As the organization is the usual filter for security, when the user wants to define the security filter based on the organization of a field, it is not necessary to include the organization of the field in the security control. In the security filter the user will define that the security is based on the organization. | Should have | To be planned |
| 4.3 | Definition of security filters.
A security filter has the following data:
For each field included in the security filter, it is necessary to define:
| Should have | To be planned |
| 4.4 | Definition of permissions.
To define a permission of a role, it is necessary to specify:
| Must have | To be planned |
| 4.5 | The permissions defined are tested when a user wants to see a screen and also when he is going to save a new register. A user can not introduce a register that he is not allowed to edit. | Must have | To be planned |
Management of Organization data
| Num | Requirement | Importance | Status |
|---|---|---|---|
| 5.1 | Selection of the current organization.
When a user logs in in the application, he selects an organization in the same way he selects a role or language (current behavior). This organization is shown with the information of the user. | Should have | To be planned |
| 5.2 | Modification of current organization.
A user can change of organization, selecting the organization from a como box without opening the profile window. | Nice to have | To be planned |
Organization specific data
| Num | Requirement | Importance | Status |
|---|---|---|---|
| 6.1 | Definition of organization specific fields.
Organization specific fields are fields that can have different values for each organization. They have the following features:
The definition is made in the dictionary with the other fields of the tab, indicating that it is an organization specific field. Ecah one has a check to define if the owner of the record has permission tochange the values when the data has been changed for an ascendent organization. This is specific of each field, because some fields may have sense to be changed by the owner (technical feature) and other by a management organization (price). | Must have | To be planned |
| 6.2 | Display of organization specific fields.
When the user sees a tab, he can identify the fields that are organization specific fields because they have an specific icon to show an change the values for all organizations. The value showed in the tab for the organization specific fields are the values for the organization defined in their profile. | Must have | To be planned |
| 6.3 | Modification of organization specific fields.
When the record is created, the value is copied to all the organizations. When the user edits an organization specific field, if the working organization is the same as the organization of the register (he owns the register), he changes all the values except of the organizations that have themselves changed the value (ascendent and descendent way). When the user edits an organization specific field, if the working organization is different from the organization of the register, he changes all the values of the descendent organizations except of the organizations that have themselves changed the value (descendent way). To change the values that have been changed by other organizations, the user has to open the specific window. | Must have | To be planned |
| 6.4 | Specific window to change any value of an organization specific field.
It's a window that shows the hierarchy of the organizations and the value of the organization specific field for them, and who is the organization that has made the last change. In this window, the user can change the values of the organizations he has permission. These organizations are:
| Should have | To be planned |
| 6.5 | Creation of a new organization.
When a new organization is created, it’s necessary to include the values for the existing organization specific fields. The value must be the value of that field for the parent organization. If it is the root organization, the value is the value of the organization that owns the record. | Must have | To be planned |
User Interface Mockups
The image below is a mock up of the definition of filter security screen.
Technical Requirements
None.
Non-Functional Requirements
None.
Open Discussion Items
The first iteration is completed (Accounting and Period Control), but it remains the necessary modifications for theInitial Client Setup and Initial Org Setup which depend on the modularity project. So, when the modularity project is finished and merged into the trunk, this scripts will be created.