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

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.

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.

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