Organizations and Oracle Projects (11i)

An Oracle White Paper June 2001 Revised January 2002

Organizations and Oracle Projects

ORGANIZATIONS OVERVIEW

Before diving into the role played by organizations within Oracle Projects, we need to set the background by viewing organizations in the applications as a whole. We need to define the terms related to organizations, discuss their attributes, how they are set up, and what functions they serve generally within Oracle applications.
Definitions

An understanding of the following terms is crucial to understanding organizations within oracle applications:
Organization

Organizations are potentially any grouping within a company or enterprise. They can be departments, sections, divisions, companies, cost-centers, or virtually any other organizational unit within a business. Within Oracle applications organizations are shared among all of the applications. They are defined and stored using HR forms and tables, but are used by all applications that require them.

Organization Classification

Organizations serve many different purposes within the distinct applications. Organization classifications are assigned to individual organizations to indicate what functions they will perform. A single organization may serve many different functions. Each of these roles is assigned to the organization via an organization classification. Each organization classification may have one or more descriptive flexfields associated with it which allow users to enter additional information related to that classification. Below we will define some of the major organization classifications.

Business Group

Generally the Business Group classification indicates that the organization represents the highest level or largest organizational unit of an enterprise. All organizations, employees, and organization hierarchies are assigned to a business group. The value of this business group is controlled by the setting of the HR: Business Group profile option. (PER_BUSINESS_GROUP_ID) in the responsibility that is creating them. As a result, you must define your business group first and then set this profile option in order to define other organizations.

Legal Entity

A legal entity is an organization representing the legal company. It is the entity recognized by government and legal authorities, which issues pay, withholds taxes, and prepares government mandated reports. Each Legal Entity is associated with a single Set of Books (see below).
Set of Books

A set of books is neither an organization, nor an organization classification. It is a financial reporting entity that partitions General Ledger information. Each set of books is defined by its chart of accounts (i.e., its Accounting Key Flexfield structure), its currency, and its calendar. Although Set of Books is not an organization classification, it is part of the additional information that is assigned to Legal Entities

Operating Unit

Also an organization classification, operating units are directly tied to MultiOrg functionality within Oracle applications. This will be discussed in further detail below. The term Multi-Org, in fact, refers to multiple operating units. Each operating unit represents a partition of data in various subledger applications (eg, Payables, Receivables, Projects, etc.) The data a user sees in these applications is dependent on the operating unit he is working in. This is controlled by the setting of the profile option MO: Operating Unit (ORG_ID) for the responsibility the user is logged in to. Each operating unit is assigned to a single legal entity (and thereby a set of books).

HR Organization

An organization must have this classification in order to be used in employee assignments.

Inventory Organization

Organizations with this classification are used by used by Inventory and Manufacturing applications to track inventory transactions and balances.

Organization Tables & Data Structure

The basic organization information is stored in the following tables: HR_ALL_ORGANIZATION_UNITS HR_ORG_INFORMATION_TYPES HR_ORG_INFO_TYPES_BY_CLASS HR_ORGANIZATION_INFORMATION HR_LOOKUPS

HR_ALL_ORGANIZATION_UNITS

Stores one record per organization, with basic organization information such as the name, effective dates, location, and business group.
HR_ORG_INFORMATION_TYPES

This table holds pre-seeded information. Each record describes a particular type of information that can be stored in the hr_organization_information table. Examples are: Legal Entity Accounting information and Project Burdening Hierarchy
HR_ORG_INFO_TYPES_BY_CLASS

The various information types defined in hr_org_information_types are generally only relevant for a particular classification. This table therefore indicates what information types are valid for what organization classifications. There is one record for each valid classification/information type combination. For example, the Legal Entity Accounting information type is only valid for the Legal Entity organization classification. The Project Burdening Hierarchy information type is only valid for the Business Group classification. This data, like that in hr_org_information_types, is pre-seeded and is not maintained in any form.
HR_ORGANIZATION_INFORMATION

This table stores both the classifications for an organization and the data for the information types associated with those classifications. The column ORG_INFORMATION_CONTEXT indicates what type of information is being stored in a given record. The actual data is stored in the columns ORG_INFORMATION1 ORG_INFORMATION20. When ORG_INFORMATION_CONTEXT=CLASS, this indicates that the

information being stored is an organization classification. The classification is stored in ORG_INFORMATION1 and the enabled flag is stored in ORG_INFORMATION2. Therefore to view the classifications for a given organization, you could use the following select:
Select org_information1 classification, org_information2 enabled_flag, from hr_organization_information where organization_id = &organization_id and org_information_context = CLASS;

The descriptive flexfield that maps the pieces of information stored for each information type to the org_information columns (1-20) is called Org Developer DF. The information type is the context field for the flexfield. So in order to determine what columns contain what data for a given information type you could use something like the following:
select end_user_column_name data_element, application_column_name column_stored_in from fnd_descr_flex_column_usages where descriptive_flexfield_name = 'Org Developer DF' and descriptive_flex_context_code = '&info_type';
HR_LOOKUPS

The organization classifications are stored in HR_LOOKUPS. The lookup_type is ORG_CLASS. The lookup_code value is stored in hr_organization_information, the meaning column is displayed in forms.

ORGANIZATIONS IN ORACLE PROJECTS

We have seen some of the basic information related to organizations, different classifications and how organization information is stored. Now let us examine organizations specifically as they relate to Oracle Projects.
Organization Classifications Used by Projects

There are numerous organization classifications that are used by projects. Many of those described above are used by projects just as they are by any other application (e.g., Business Group, HR Organization, and Operating Unit), but there are also some classifications that are very specific to Oracle Projects.
Project Expenditure/Event Organization (PA_EXPENDITURE_ORG)

Organizations with this classification may be charged. Usually, unless there are organization overrides in place, the expenditure organization of a transaction in Projects is the employees assigned organization (for time and expenses) or the entered organization (for usages or supplier invoices). It is the organization providing the resource to the project. For cross charging purposes, the expenditure organization is the provider organization. To act as an expenditure organization, an organization must have this classification and be an element of the Expenditure/Event Organization hierarchy specified in the system

implementation options form. It must also appear in the hierarchy at or below the Start Organization specified in the implementation options. Hierarchies will be discussed in more depth below.
Project Task Owning Organization (PA_PROJECT_ORG)

Organizations with this classification may be assigned to projects and tasks. These organizations own the project or task. For cross charge purposes they are the receiving organization. To act as a project or task owning organization, an organization must have this classification and be a member of the Project / Task Owning Organization hierarchy specified in the system implementation options form. It must also appear in the hierarchy at or below the Start Organization (also specified in the implementation options form).
Project Invoice Collection Organization (PA_INVOICE_ORG)

Organizations with this classification are used for decentralized invoicing. When using decentralized invoicing, two transaction types are created in Oracle Receivables for each invoice collection type organization. One for invoices and one for credits. When invoices (or credits) are transferred to Receivables, they are assigned a transaction type based on the first invoice collection organization in the Project / Task Owning organization hierarchy at or above the project owning organization for the project. So, for example, suppose that the Vision Services organization owns a particular project, and that invoices for this project are being transferred to Receivables. If Vision Services is an invoice collection organization, then the transaction types used will be the ones associated with Vision Services itself. If Vision Services is not an invoice organization, then the process will search up the project/task hierarchy starting with Vision Services until it finds the lowest organization that is an invoice collection organization, and it will use the transaction types associated with that organization.
Organization Tables & Data Structure for Projects

Projects obviously uses all of the tables described in the prior section, as it shares this information with all other applications. However, much of the most frequently used information from those tables is stored in a denormalized fashion in a local Projects table PA_ALL_ORGANIZATIONS.
PA_ALL_ORGANIZATIONS

This table stores a list of all expenditure and project owning organizations. The information in this table is based on the organization classifications and hierarchies mentioned above. Most organization LOVs in the Projects application are based on this table. It consists of only 4 columns: ORGANIZATION_ID Identifier for the organization ORG_ID Identifier for the operating unit in which the organization is being used. PA_ORG_USE_TYPE Either PROJECTS or EXPENDITURES to indicate which this organization is being used for.

INACTIVE_DATE Null if the organization is current, otherwise the date at which the organization ceased to be used for the indicated purpose.

There are numerous issues relating to this table, because in many cases the values are not updated when they should be. For example, if I disable the Project Expenditure/Event Organization classification for an organization, I would expect that change to be reflected in this table; however, in many cases it is not. One sure way to guarantee that this table has the most up to date information is to change the Start Organization for the expenditure or project hierarchy in the implementation options form. If you change this value, save, and then change it back, it will result in a call to PA_ORG_UTILS.START_ORG_CHANGED which, in turn, will result in this table being refreshed based on the most current data in the HR tables. See the following bugs for some of the issues relating to the data in this table: Disabling expenditure and project classifications in HR does not remove/disable the organization in pa_all_organizations. Existing bugs for this issue: 11.0: -1635760 (One off on top of PA.F) -1740727 (Backport for 1635760 to 11.0.PA.E and, per bug 1837263 this can be applied on top 11.0.PA.D as well. -Code fix included in 11.0.PA.H -1278894 (datafix on top of PA.E) 11.5: -1735681 (One off on top of 11i.PA.D) -Codefix included in 11i.PA.E -Data fix not provided. 1180635 (11.0) Start organization for project and expenditure hierarchies is included in pa_all_organizations, even if the classification is not enabled for that organization. 1657676 (11.5) & Doc bug 1674878 If multi-org is not implemented, but the MO: Operating Unit is set, the records in pa_all_organizations get incorrectly created with a non-null ORG_ID.

MULTIPLE ORGANIZATIONS (MULTI-ORG) CONSIDERATIONS

As mentioned briefly above when we defined the Operating Unit organization classification, the Multi-Org feature of oracle applications is a means of partitioning data. Prior to Release 10.7, similar functionality was only possible by having several distinct installations of a particular module. With multi-org functionality, however, the same result is achieved in a single install. When you log into a responsibility that points to a particular operating unit (via the profile option MO: Operating Unit) you only see and work with data for that operating unit.

How does it work?

How does the application display only the data that is related to your current operating unit?
Multi-Org Views

Not all tables are partitioned. For example, in Projects expenditure types are shared among all operating units. In this case there is no partitioned view. See Multiple Organizations in Oracle Applications for a full list of partitioned tables by application.

The basis of the multi-org functionality are views which dynamically filter the information in your base tables, only showing the portion of the data that relates to your current operating unit. Beginning in Release 10.7, a 64-byte global database variable CLIENT_INFO exists in the database. The first 10 bytes of this variable are used to store the current operating unit. Base tables whose data must be partitioned, generally contain the suffix _ALL (e.g., PA_PROJECTS_ALL is a base table containing project information for all operating units). These tables all have an ORG_ID column. This column indicates the organization_id of the operating unit to which the data relates. A partitioned view is created based on this underlying table. This view simply selects all the columns (except ORG_ID) from the base table, and adds in the condition:
Where NVL(ORG_ID, NVL( TO_NUMBER( DECODE( SUBSTR(USERENV(CLIENT_INFO),1,1), , NULL, SUBSTR(USERENV(CLIENT_INFO),1,10) ) ), -99) ) = NVL( TO_NUMBER( DECODE( SUBSTR(USERENV(CLIENT_INFO),1,1), , NULL, SUBSTR(USERENV(CLIENT_INFO),1,10) ) ), -99)

So what does all this mean? The first part of the equation will return the ORG_ID from the table if this is not null. If it is null it will check the first character of the CLIENT_INFO database variable. If that character is blank, it will return 99, if not, it will return the first ten characters of CLIENT_INFO (which should be storing the current operating unit id). The second half of the equation just looks at the CLIENT_INFO variable and returns 99 if the first character is blank (operating unit is not set), or the first 10 characters (operating unit id) otherwise. So basically, if the tables ORG_ID is null, meaning that Multi-Org has not been implemented, then this will always return the row because both sides of the

equation will return 99 if CLIENT_INFO is not set and the value of CLIENT_INFO if it is. If ORG_ID is not null, it will only return the row if CLIENT_INFO is set with the operating unit (not null), and that operating unit matches the ORG_ID in the table.
Populating the ORG_ID column

How does the ORG_ID column get correctly populated in the base tables when you save a new record to this view if the view does not have the ORG_ID column in it? When the base tables are defined, a default value is defined for the ORG_ID column as follows:
to_number(decode( substrb(userenv('CLIENT_INFO'),1,1), ' ',null, substrb(userenv('CLIENT_INFO'),1,10)))

Therefore, whenever a record is inserted to the partitioned view, even though no value is specified in the insert statement, the current value of the operating unit id in CLIENT_INFO will be inserted into the table. In some cases when customers import and export databases, this default definition for the ORG_ID column gets lost, resulting in records being inserted into the base tables with a null ORG_ID.
Setting the CLIENT_INFO Variable

The easiest way to set the CLIENT_INFO variable is to do so directly:

execute dbms_application_info.set_client_info(&org_id);

This will set the first characters of the variable to whatever org_id value you supply. However, when you actually log into applications, only the first 10 characters will be used for the ORG_ID, the rest of the variable is used to store other information. Characters 45-54 are used for currency context information. This stores the reporting set of books id from the profile option MRC: Reporting Set Of Books if this is set. Characters 55-64 are used to store the HR security group id. The procedure fnd_global.initialize can be called with the user_id, responsibility_id, and application_id as parameters to set the CLIENT_INFO variable as it would be set if you logged in to the specified responsibility as the specified user. This procedure will only set the operating unit portion of CLIENT_INFO when Multi-Org has been implemented, that is, if the value of FND_PRODUCT_GROUPS.MULTI_ORG_FLAG is Y. If not, it will ignore the value of the MO: Operating Unit profile option and will leave the first ten characters of CLIENT_INFO blank.

ORGANIZATION HIERARCHIES OVERVIEW

An organization hierarchy is essentially a means of defining the hierarchical relationships between the different organizations that make up a business. It is a multi-level representation of the companys organizational structure. A good rule of thumb is that the Business Group (as the broadest organizational entity) should be the top organization of the hierarchy, though this is not a requirement.
Hierarchy Revisions

Each hierarchy you define can have multiple revisions. The effective dates for different revisions may not overlap. Each revision consists of a set of parent/child organization relationships.

Basic rules for a hierarchy version include: 1) An organization may not be its own subordinate. 2) The top organization of the hierarchy is the only one with no parent organization. When defining a hierarchy you should be careful that a single organization does not appear anywhere below itself in the hierarchy. It is possible to create such a structure; however, hierarchical queries that use a start with and connect by clause to traverse the hierarchy will fail in this case with ORA-1436: CONNECT BY loop in user data.

Organization Hierarchy Tables & Data Structure

Information related to organization hierarchies is stored in the following tables: PER_ORGANIZATION_STRUCTURES PER_ORG_STRUCTURE_VERSIONS PER_ORG_STRUCTURE_ELEMENTS

10

PER_ORGANIZATION_STRUCTURES

This table contains one record per organization hierarchy. Each record contains the basic information about the hierarchy, including its name, unique id, business group id, and primary flag. Only one hierarchy per business group may have PRIMARY_STRUCTURE_FLAG = Y.
PER_ORG_STRUCTURE_VERSIONS

This table holds information about version number, start and end dates, and whether or not the current version was copied from an existing hierarchy version. Version effective dates cannot overlap within a single hierarchy.
PER_ORG_STRUCTURE_ELEMENTS

This table holds the actual organization structure information. Each record indicates the parent/child relationship between two organizations in the hierarchy. ORGANIZATION_ID_PARENT indicates the parent organization, and ORGANIZATION_ID_CHILD indicates the child organization. The top organization in the hierarchy is the only organization for which there is a record in which it is the parent, but no record where it is the child. Each time an organization is added to the hierarchy, a record is inserted into this table. To traverse the hierarchy, you can use a select similar to the following. This will show the information in a hierarchical format, indenting lower levels of the hierarchy:
select lpad(to_char(organization_id_parent), level*3) parent, organization_id_child from per_org_structure_elements where org_structure_version_id = &structure_version_id connect by prior organization_id_child = organization_id_parent and prior org_structure_version_id = org_structure_version_id start with organization_id_parent=&starting_org_id and org_structure_version_id=&structure_version_id;

ORGANIZATION HIERARCHIES IN ORACLE PROJECTS

Oracle Projects uses organization hierarchies for various purposes. They are used to determine valid expenditure and project owning organizations, in decentralized invoicing, in determining burdened amounts using a burden schedule, and for reporting purposes.

11

Oracle Projects Specific Hierarchies

There are four hierarchies used by Oracle Projects. For each you must specify both the organization hierarchy and the version you wish to use. They are: Default Reporting Organization Hierarchy Expenditure/Event Organization Hierarchy Project/Task Owning Organization Hierarchy Project Burdening Hierarchy
Default Reporting Organization Hierarchy

This Organization Hierarchy/Version is specified in the implementation options form as the default hierarchy for Oracle Projects to report information associated with a group of organizations. For some reports, the rollup relationships within the organization hierarchy are used to report the accumulated project activities. If an organization is missing in the selected Reporting Organization Hierarchy Version, the project activity is not reported. This hierarchy is used by the following reports: MGT: Employee Activity By Organization (PAXEMRAO.rdf) MGT: Project Billing Status (PAXMGPBS.rdf) MGT: Invoice Review (PAXINGEN.rdf) IMP: Labor Cost Rates By Organization (PAXRWLCO.rdf) IMP: Employee Assignments By Organization (PAXPEEMO.rdf) FLW: Invoice Flow Summary (PAXPCIFS.rdf) FLW: Invoice Flow Detail (PAXPCIDF.rdf) AUD: Expenditure Batch Status (PAXPCEGS.rdf)

12

It is mainly used via the view PA_ORG_REPORTING_VIEW. To use this view, reports will insert a record into the table PA_ORG_REPORTING_SESSIONS consisting of the current session id (from USERENV(SESSIONID)) and a starting organization id. PA_ORG_REPORTING_VIEW will then traverse the default reporting hierarchy and return all organizations below the starting organization from PA_ORG_REPORTING_SESSIONS for the current session.
Expenditure/Event Organization Hierarchy

This organization hierarchy/version is also specified in the implementation options form, and as such is specific to the operating unit in which it is assigned. Its purpose is to determine what organizations can own events and incur costs. In order to perform these activities in a particular operating unit, an organization must have the Project Expenditure/Event Organization classification and must be a member of this hierarchy/version, appearing in the hierarchy at or below the start organization specified in the implementation options.
Project/Task Owning Organization Hierarchy

Like the expenditure organization hierarchy, this is also an implementation option (assigned under the Project Setup tab), and as such is specific to the operating unit in which it is assigned. Its purpose is to determine what organizations can own and manage projects and tasks. In order to perform these activities in a particular operating unit, an organization must have the Project/Task Owning Organization classification and must be a member of this hierarchy/version, appearing in the hierarchy at or below the start organization specified in the implementation options.

13

Project Burdening Hierarchy

Unlike the other three hierarchies, the Project Burdening Hierarchy is not an implementation option. Rather it is specified at the business group level, so it is shared across all operating units associated with a particular business group. Also unlike the other hierarchies, once assigned, you cannot update the value of this hierarchy/version. Any modifications to the burdening hierarchy structure must be made on the version originally assigned to the business group.

The purpose of this hierarchy is to aid in determining burden amounts from burden schedules. When a burden schedule is defined, burden multipliers are assigned to individual burden cost code/organization combinations. When the burden schedule is used to calculate the burden amount for a given transaction, first the system determines the organization for the transaction. If there is a multiplier defined for that organization, then it will be used. If not, the system will climb up the burden hierarchy starting with the transaction organization until it finds the first organization for which multipliers are defined and it will use the multipliers assigned for that organization.
Hierarchy Related Tables & Data Structure

Projects does not have any tables specifically related to organization hierarchies; however, we can see where the hierarchy assignments information is stored. For the default reporting hierarchy, the expenditure /event hierarchy, and the project/task owning hierarchy this information is stored in

14

PA_IMPLEMENTATIONS_ALL. The burden hierarchy information is stored in HR_ORGANIZATION_INFORMATION.

Reporting, Expenditure & Project Hierarchies

As mentioned the above, assignment information for these three hierarchies is stored in PA_IMPLEMENTATIONS_ALL. This table stores one record for each implemented operating unit. Each assignment consists of three values: 1) the organization structure id 2) the structure version id and 3) the starting organization id. The columns from PA_IMPLEMENTATIONS_ALL that store each of these three values are indicated below:

Default Reporting Organization Hierarchy 1. ORGANIZATION_STRUCTURE_ID 2. ORG_STRUCTURE_VERSION_ID 3. START_ORGANIZATION_ID Expenditure/Event Organization Hierarchy 1. EXP_ORG_STRUCTURE_ID 2. EXP_ORG_STRUCTURE_VERSION_ID 3. EXP_START_ORG_ID Project/Task Owning Organization Hierarchy 1. PROJ_ORG_STRUCTURE_ID 2. PROJ_ORG_STRUCTURE_VERSION_ID 3. PROJ_START_ORG_ID
Project Burdening Hierarchy

The project burdening hierarchy is assigned to the business group. When you assign the business group classification to an organization, one of the additional information flexfields associated with that classification is the Project Burdening Hierarchy. Therefore, this information is stored in HR_ORGANIZATION_INFORMATION as additional information for your business group. You can use the following query to view this information for all of your operating units:
col struct_id for a5 hea STRID col name for a25 hea NAME col vers_id for a5 hea VERID select pi.org_id OpUnit, org_information1 struct_id, s.name, org_information2 vers_id, v.version_number from pa_implementations_all pi, hr_organization_information i, per_organization_structures s, per_org_structure_versions v where i.organization_id = pi.business_group_id and i.org_information_context = 'Project Burdening Hierarchy'

15

and and

s.organization_structure_id = to_number(org_information1) v.org_structure_version_id = to_number(org_information2);

16

Organizations and Oracle Projects June 2001 Revised January 2002 Author: Andrew Lumpe Copyright Oracle Corporation 2001 All Rights Reserved Printed in the U.S.A. This document is provided for informational purposes only and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document. Oracle is a registered trademark and Enabling the Information Age is a trademark of Oracle Corporation.

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: 415.506.7000 Fax 415.506.7200 Copyright Oracle Corporation 1995 All Rights Reserved

17