View source | View content page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

Projects:EnhancedMulti-organizationSupport/Specifications-tmp

Contents

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


Dependencies

None.


Constraints

See Design Considerations.


Glossary


Functional Requirements

User roles & profiles

The target users for this project are:


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


Story 2: User access


Story 3: Specific data values


Story 4: Accounting
Story 5: Document organization
Story 6: Period control
Story 7: Organization specific data


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:
  • Legal entity
  • Business unit organization

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:

  • Open a period: for the organization selected, the user can open only the documents of the selected organization or can open all the organizations that depend on it.
  • Close a period: the close of the period is marked only in the select organization but it affects to all the organizations that depend on it.

The open and close of a period is made selecting the following information:

  • Organization (when the organization is selected, it shows the Calendar of this organization for information purpose).
  • Year
  • Until period (it is open or closed from the last document open or closed)
  • Base Document Type: if it is not defined, all the documents are closed or opened.
  • Action: Open, Close and Permanent close

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:

  • the period control for that document and organization must be created
  • all the existing period controls for that document from the organization until the root of the calendar should not be closed (there is not need that all the period control documents until the root to be created).

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:
  • Extend ascendant
  • Extend descendant

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:

  • Header of the security filter
  • List of security controls included in the filter

For each field included in the security filter, it is necessary to define:

  • Security control used for this row of the filter
  • Type of comparison, the possible values are: =, <, >, <>, from - to, begins with, ends with, includes.
  • A value
  • A secondary value for the “from – to” comparison option
  • A check for the case the security is based in the Organization
Should have To be planned
4.4 Definition of permissions.

To define a permission of a role, it is necessary to specify:

  • Role for the permission
  • Security object (product, order, shipment …)
  • Organization (currently the permissions are for all the organizations, but a fine tuned security needs to define the organization for the permission)
  • Permission for Reading or Writing (R/W)
  • Extend permission ascendant for reading (Yes/No) (the default value is copied from the definition in the security object)
  • Extend permission descendant for reading (Yes/No) (the default value is copied from the definition in the security object)
  • Security filters applied (several filters can be applied, they are added with the logical OR)
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:

  • An organization specific field is defined for the whole application, it is shown for all clients and organizations.
  • It is possible to filter by an organization specific field
  • It is possible to sort by an organization specific fields
  • The value of a organization specific field is saved for every organization, even when the value is the same for all them.

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:

  • all organizations that the last change has been made for the current organization
  • all descendent organization
  • if the organization is the owner of the record and the field's owner check is set to true, the ascendent organizations and descendent of these.
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.

FilterSecurityScreen.jpg

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.

Retrieved from "http://wiki.openbravo.com/wiki/Projects:EnhancedMulti-organizationSupport/Specifications-tmp"

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