Organizations and Oracle Projects (11i) An Oracle White Paper June 2001 Revised January 2002

1

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.

2

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”

3

Operating Unit

Also an organization classification, operating units are directly tied to “Multi-Org” 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).

4

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

5

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 employee’s 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

6

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 LOV’s 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.

7

�� 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.

8

How does it work? How does the application display only the data that is related to your current operating unit?

Multi-Org Views

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 table’s ORG_ID is null, meaning that Multi-Org has not been implemented, then this will always return the row because both sides of the

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.

9

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.

10

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 company’s 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

11

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.

12

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)

13

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.

14

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

15

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'

16

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

17

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