Organizations

This chapter discusses three integral aspects of the Oracle Projects application suite: organizations, jobs, and resources.

Oracle Projects shares organization, job, and employee information with Oracle Human Resources. If your business does not currently use Oracle Human Resources, you define this data using the Oracle Human Resources windows provided with Oracle Projects.

Your implementation of Oracle Human Resources to work with Oracle Projects involves the definition of:

• Organizations and organization hierarchies

• Jobs

• Resource information

The structure of your enterprise determines how you define your organizations, business groups, hierarchies, jobs, and job groups.

This chapter covers the following topics:

• Organizations
• Case Study: Organization Change in Fremont Corporation

Organizations

The organizations and organization hierarchies of an enterprise are closely interrelated with the policies and procedures of that enterprise. To configure Oracle Projects to meet your business requirements, you must make critical implementation decisions regarding how you set up your organizations in Oracle Projects.

Organizations are departments, sections, divisions, companies, or other organizational units in your enterprise. You can gather collections of organizations into organization hierarchies. Organization hierarchies make it easier to manage expenditure and reporting data and coordinate the project-owning organizations within your enterprise.

For optimum control, consistency, and trend analysis, it is simplest to keep the organization definitions stable. However, in a dynamic business environment, changes to organizations and organization structures are inevitable. When your organization structure changes, it is very important to understand the implications to your Oracle Projects implementation.

You can change the organization hierarchy setup in Oracle Projects to reflect changes to your company's organization hierarchy. To maintain system control and enforce your business rules, it is important to plan and manage the change carefully. To do this, you must understand how organizations and organization hierarchies are used in Oracle Projects.

Related Topics

Organization Definition, Oracle Projects Implementation Guide

Representing Organizations, Oracle HRMS Enterprise and Workforce Management Guide

Creating an Organization, Oracle HRMS Enterprise and Workforce Management Guide

Defining Organizations

Organizations can represent departments, sections, divisions, companies, business groups, or other organizational units within your enterprise. You can also create organizations that represent your external contractors.

Oracle Projects uses organizations for the following business purposes:

• Management of projects and tasks

• Employee assignments

• Expenditure entry

• Non-labor resource ownership

• Budget management

• Resource definition for project status reporting

• Burden cost processing

• Invoice and collections processing

• Reporting

You use the Organization window to define all the organizations within your business group. The organizations you define appear in lists of values in the Organization Name fields throughout Oracle Projects.

Important: When you define organizations, you need to assign Organization Classifications to each organization that you want to use in Oracle Projects. See: Types of Organizations.

Example: Fremont Corporation Organizations

Fremont Corporation consists of four divisions (Administration, Fremont Engineering, Fremont Construction, and Fremont Services), each of which includes several groups. The following table shows the information that Fremont's implementation team enters to define its organizations. All the organizations are internal.

For all of Fremont Corporation's organizations, the following organization classifications are enabled:

• Project/Expenditure/Event

• Project Invoice Collection

Some of Fremont's organizations are shown in the following table:

Organization Name	Location
Administration	HQ
Data Systems	HQ
East	East
Electrical	HQ
Finance	HQ
Fremont Construction	HQ
Human Resources	HQ
International	International
Midwest	HQ

Types of Organizations

You can define the following types of organizations for different uses in Oracle Projects:

Business Group

A business group is the largest organizational unit you can define to represent your enterprise. A business group may correspond to a company or corporation, or in large enterprises, to a holding or parent company or corporation.

Important: Employees, organizations, and other entities are partitioned by business group. If you set up more than one business group, your data will be partitioned accordingly. In addition, classifying an organization as a business group is not reversible. Be sure to plan your business group setup carefully.

For more information, see Business Groups.

Operating Unit

An operating unit is used to partition data for a subledger product (for example, Oracle Projects or Oracle Payables). It is roughly equivalent to an enterprise that uses a single organization.

When an enterprise uses more than one operating unit, it is said to have a multiple organization installation. You can enter and process transactions in two or more operating units without switching responsibilities, with multiple organization access control.

Organization classifications involving financial transactions (such as expenditure/event organizations, billing schedule organizations, and project invoice collection organizations) are always associated with operating units.

For more information, see Operating Units and Multiple Organizations and Security In Oracle Projects.

Project/Task Owning Organizations

Project/Task Owning Organizations can own projects and/or tasks in the operating unit. To own projects and tasks in an operating unit, an organization must have the following characteristics:

• The Project/Task Owning Organization Classification must be enabled.

• The organization must belong to the Project/Task Owning Organization Hierarchy Branch assigned to the operating unit.

Project Expenditure/Event Organizations

Project Expenditure/Event Organizations can own project events, incur expenditures, and hold budgets for projects in the processing operating unit, unless they are overridden by projects or tasks using organization overrides. To have these capabilities in the operating unit, an organization must have the following characteristics:

• The Project Expenditure/Event Organization classification must be enabled.

• The organization must belong to the Expenditure/Event Organization Hierarchy Branch assigned to the operating unit.

For more information, see Defining Expenditure/Event Organizations for Resource Expenses.

Expenditure Organization

For timecards and expense reports, the organization to which the incurring employee is assigned, unless it is overridden by project or task using organization overrides.

For usage, supplier invoices, and purchasing commitments, the expenditure organization is the organization entered on the expenditure.

HR Organization

Any organization that has the HR Organization classification enabled can have employees assigned to it.

You don't need to enable the HR organization classification for Oracle Projects unless you want to assign employees to the organization.

Resource Organizations

Resource Organizations are organizations that own resources and/or resource budgets. Any organization in the operating unit's business group can own non-labor resources.

• Only HR organizations can have employees assigned to them.

• Oracle Projects does not have a classification requirement for an organization to own non-labor resources.

Billing Schedule Organizations

Billing Schedule Organizations are organizations that have their own billing schedules.

Any organization in the operating unit's business group can have its own billing schedules.

Project Burdening Hierarchy Organizations

Burdening for costing uses the Project Burdening Hierarchy Version for both the burden cost code multiplier setup and burdening. Each business group must designate a single organization hierarchy as its default project burdening organization hierarchy. This default can be changed for each burden schedule or each burden schedule version.

The Project Burdening Hierarchy defaults to the burden schedule from the business group organization definition. You set up different burden schedules if your business allows different ways to burden costs.

• Oracle Projects lets you assign burden multipliers to organizations in the Project Burdening Hierarchy Version. You can only assign burden cost code multipliers to organizations that are in the Project Burdening Hierarchy Version.

• Oracle Projects uses the Project Burdening Hierarchy Version associated with the burden schedule to calculate burdened cost. If Oracle Projects does not find the expenditure organizations in the Project Burdening Hierarchy Version during burden processing, the expenditure item is not burdened, and the burdened cost is equal to the raw cost.

For more information on burdening for costing, see Overview of Burdening, Oracle Project Costing User Guide.

Project Invoice Collection Organizations

If your business decentralizes its invoice collection within an operating unit, you must enable the Project Invoice Collection Organizations classification for each organization in which you want to process invoices.

Oracle Receivables uses transaction types to determine whether a transaction generates an open receivable balance and whether it posts to Oracle General Ledger. Each operating unit in Oracle Projects has at least two default transaction types to process invoices in Oracle Receivables. See Defining Transaction Types for Invoice Processing, Oracle Projects Implementation Guide.

If your business decentralizes invoice collection, you must run the IMP: Create Invoice Organization Transaction Types process before you can successfully run the Interface Invoices to Oracle Receivables process. The IMP: Create Invoice Organization Transaction Types process creates a transaction type for each of the Project Invoice Collection Organizations that has the following characteristics:

• The organization has the Project Invoice Collection Organization classification enabled.

• The organization belongs to the Project/Task Owning Organization Hierarchy Branch assigned to the operating unit.

Oracle Projects uses the default transaction type if it cannot find a rollup project invoice collection organization for the invoice.

Defining a Default Operating Unit for Project Expenditure/Event Organizations

To enable an organization to own project events, incur expenditures, and hold budgets for projects, you must perform the following when you define the organization:

• Enable the Project Expenditure/Event organization classification

• Define a default operating unit for the organization in the Additional Organization Information section.

In addition, if this organization supports schedulable resources, you must perform the following:

• Select Related Organizations in the Additional Organization Information section

• Enter the default operating unit for the organization

Note: You can also define a default operating unit for the organization classification HR Organization by selecting Related Organizations in the Additional Organization Information section. However, if you are using the operating unit for Oracle Projects, you must enable the Project Expenditure/Event Organization classification.

For instructions on performing these tasks, refer to the following topics in the Oracle HRMS Enterprise and Workforce Management Guide:

• Creating an Organization

• Entering Organization Classifications

• Entering Additional Information

Defining Project Expenditure/Event Organizations for Resource Expenses

You typically use expenditure organizations to track expenses related to project resources. Project Expenditure/Event organizations can own project events, incur expenditures, and hold budgets for projects. To enable these capabilities in the organization, you must perform the following tasks as you define it:

• Enable the Project Expenditure/Event organization classification.

• Define a default operating unit for the organization in the Additional Information section. This step causes all resources belonging to this organization to inherit the specified operating unit and calendar as their default operating unit and calendar.

• Enable the HR Organization classification. This task is necessary in order to have the ability to assign resources (people) to the organization.

• Attach the organization to the Expenditure hierarchy assigned to the operating unit using the Setup Implementation Options form.

For instructions on performing these tasks, refer to the following topics in the Oracle HRMS Enterprise and Workforce Management Guide:

• Creating an Organization

• Entering Organization Classifications

• Entering Additional Information

Related Topics

Case Study: Organization Change in Fremont Corporation

Organization Security

Organization Definition, Oracle Projects Implementation Guide.

Business Groups

The business group organizations you define represent each legislative unit under which your business operates. Within each business group, you can define organizations to represent the structure of your enterprise.

Organizations and employees are partitioned by business groups. Many enterprises choose to use a single business group so that they can manage and report information from all parts of the enterprise at the same time. However, companies that have foreign operations must have a unique business group for each country. This enables them to deal with local legislative requirements and to define unique structures, jobs, benefits, and compensation policies.

You can choose to have multiple business groups even if you do not have foreign operations. If you have multiple business groups, you must first define a top organization that will encompass all business groups.

Within each business group you define the groupings in which employees work, such as divisions, branches, departments, or sections. You also maintain information about various types of external organizations relevant to human resources, payroll, or administration. For example, you might define an organization as external to record a work site address at which employees are stationed for extended periods of time.

For more information on business groups and structuring your enterprise, see Adapting or Creating a New Business Group, Oracle HRMS Enterprise and Workforce Management Guide

Using the Cross Business Group Profile Option

In the Oracle HRMS model, the business group is at the country level and a top organization encompasses all business groups in a company worldwide. People, projects, jobs, and organizations can be located in different business groups for different countries and all information can be shared throughout the enterprise.

Oracle Projects allows the visibility of all business groups to one another. For example, you can search staff resources on projects across business groups, and charge any project across the enterprise for a resource.

You control access to single or multiple business groups by setting the profile option HR: Cross Business Group:

• Set the profile option to Yes to allow cross business group access.

• Set the profile option to No to allow only single business group access.

For more information, see: Providing Data Across Business Groups.

For information about cross business group access and Oracle Projects security, see Providing Additional User Level Security for Responsibilities.

Defining a Business Group

You use the Organization window to retrieve the view-all security profile with the same name as the business group. You enter the name of your business group to create your business group.

The business group you define appears in the list of values when you set up the HR: Security Profile profile option.

You must also define required business group information. Note that even though you must fill in a value for every segment in the Business Group Flexfield, Oracle Projects uses only the following information:

• Short name

• Employee Number Generation

• Job Flexfield Structure

• Project Burdening Organization Hierarchy

Oracle Projects defaults the Project Burdening Organization Hierarchy to each burden schedule you define. The system uses the Organization Hierarchy/Version to determine the default burden multiplier when it compiles a burden schedule. See: Project Burdening Hierarchy Organizations.

You must define the organization hierarchy before you associate it with a business group. See: Defining Organization Hierarchies.

Oracle Human Resources incorporates all other organizations that you specify into the business group that you define. See: Setting Up Security in Oracle HRMS, Oracle HRMS Enterprise and Workforce Management Guide.

Security Groups

Security groups are a method of partitioning data. When you use the standard HRMS security model, you do not use security groups. The business group is the only data partition. Responsibilities are linked to business groups. Therefore, to access different business groups, users must change responsibilities.

If you want one responsibility to be enabled for more that one business group, you must use Cross Business Group responsibility security. In this model, security groups are defined to partition data within a business group. Multiple security groups can then be linked to one responsibility, even if they partition different business groups.

To use security groups you must set the user profile option Enable Security Groups to Yes and run the Multiple Security Groups process.

Related Topics

Using the Cross Business Group Profile Option

Security in Oracle Projects

Security Groups, Configuring, Reporting and System Administration in Oracle HRMS.

Operating Units and Multiple Organizations

Operating units are another type of organization classification. You use operating units to partition data for a subledger application such as Oracle Payables, Oracle Receivables, or Oracle General Ledger. When an enterprise utilizes more than one operating unit, it is said to have a "multiple organization installation."

The implementation of multiple organizations in Oracle Projects supports multinational enterprises and enterprises with complex organizational structures.

This section explains how operating units enable Oracle Projects to charge to multiple organizations in a single installation. A multiple organization installation enables you to:

• Ensure secure data access for each operating unit

• Integrate with other Oracle Applications that support multi-organization processing

Note: If you plan to use reporting currencies with Oracle Projects, see information about reporting currencies in the Oracle Financials Implementation Guide and the Oracle General Ledger Implementation Guide.

About Multiple Organization Installations

A multiple organization installation in Oracle Projects works like this:

• A single operating unit (the project operating unit) owns each project and project template.

• Project numbers and project template numbers are unique across all operating units in a single installation.

• Customers are shared across operating units, while customer sites are associated with a specific operating unit.

• Individual operating units own customer agreements.

• You can charge, transfer, or allocate expenditures to any project as long as the expenditure operating unit and project operating unit is eligible for cross-charge. See: Cross Charge, Oracle Project Costing User Guide

• You enter and process costs in the same expenditure operating unit.

• You account for costs in the expenditure operating unit.

• You can view the Expenditure Items window in either project or cross-project mode:

  • In project mode, the window displays expenditures for a project in the project operating unit.

  • In cross-project mode, the window displays expenditures incurred in the expenditure operating unit.

• The project operating unit processes revenue and invoices for transactions from any expenditure operating units.

  • The project operating unit calculates draft revenue and draft invoice amounts using its bill rates, project billing rate overrides, or project labor multipliers.

  • The project operating unit generates revenue and invoices for project billing.

  • The project operating unit creates accounting for revenue in Oracle Subledger Accounting.

    The project operating unit interfaces invoices to Oracle Receivables.

• Transfers and splits generate transactions in the same operating unit as the original transaction, although the transfer may be to any chargeable project.

• The project operating unit submits reports that can be printed for a single project or a range of projects on project-related transactions across expenditure operating units.

• The project operating unit submits and stores project summary amounts. Project Status Inquiry performs queries on projects within the project operating unit.

• Reports for employees or organizations list all transactions entered within the operating unit from which the report is submitted.

• Each asset is capitalized from a single capital project to an Oracle Assets corporate book that is associated with the project operating unit's ledger.

Understanding the Resource Operating Unit

For security and forecasting reasons, each resource in Oracle Projects is associated with an operating unit. This operating unit is initially defaulted from the organization operating unit. The operating unit of the resource is active for the duration of an assignment. It drives forecasting based on the transfer price defined for the operating unit if the resource is assigned on a project under a different operating unit, in other words, a borrowed resource.

Oracle Project Resource Management updates the resource operating unit whenever there are changes to the employee assignment or the default operating unit originally set up for the employee. Oracle Projects tracks these changes for record-keeping purposes and allows date-specific operating unit defaults for the resource.

Related Topics

Adding Operating Units

Providing Data Access Across Business Groups

Cross Charge, Oracle Project Costing User Guide

Multiple Organizations in Oracle Applications

Using Accounting Setup Manager, Oracle Financials Implementation Guide

Defining Organization Hierarchies

Organization hierarchies provide a structure for the relationships between the organizations within your enterprise. They enable you to manage expenditure and reporting data and coordinate project-owning organizations. If your organization uses business groups, you can create project burdening organization hierarchies for each business group.

You define an organization hierarchy by telling Oracle Projects which organizations are subordinate to which other organizations. You can define one organization hierarchy or several, depending on the needs of your enterprise.

There are two basic types of organization hierarchies: ordinary organization hierarchies and global organization hierarchies. To define an ordinary organization hierarchy, you use the Organization Hierarchy window. The organization hierarchy you define there appears in a list of values in the Implementation Options window.

If you have enabled Cross Business Group Access, you can define global organization hierarchies. Global organization hierarchies can contain organizations from any business group. To define a global organization hierarchy, you use the Global Organization Hierarchy window. To access the Global Organization Hierarchy window, you must use a responsibility that is associated with a global security profile.

You can create as many organization hierarchies as you need for different reporting and processing needs, and you can create multiple versions of an organization hierarchy. Oracle Projects uses the hierarchy version to determine which organizations are used for reporting and processing.

You specify a start organization to indicate which branch of your organization hierarchy you want Oracle Projects to recognize as the top of your hierarchy for a particular purpose. If you want to use your entire organization hierarchy, your topmost organization (usually the business group) is the start organization.

The following organization hierarchy versions are assigned to each operating unit in Oracle Projects:

• A Project/Task Owning Organization hierarchy version is assigned to each operating unit. For more information, see Project/Task Owning Organizations.

• An Expenditure/Event Organization hierarchy version is assigned to each operating unit. For more information, see Project Expenditure/Event Organizations.

• A Default Reporting Organization Hierarchy Version is assigned to each operating unit. The hierarchy version can be overridden at reporting time.

• A Project Burdening Hierarchy Version is assigned to each business group. See: Specifying a Project Burdening Hierarchy.

If you currently use Oracle Human Resources, you can use existing hierarchies for Oracle Projects or create new hierarchies. If you do not currently use Oracle Human Resources, you must specify at least one hierarchy for Oracle Projects. You can change these organization hierarchy versions at any time.

Example: Fremont Corporation Organization Hierarchy

Fremont Corporation's organization hierarchy contains four organizations directly subordinate to its business group. Those organizations in turn have several subordinate organizations of their own.

As per the following illustration of Fremont Corporation's organization hierarchy, Fremont Corporation's four divisions are further divided into the following groups:

• Administration has four groups: the Executive Office, Human Resources, Finance, and Information Services.

• Fremont Engineering has four groups: Electrical, Mechanical, Structural and Environmental.

• Fremont Construction has five groups: West, Midwest, East, South and International.

• Fremont Services has two groups: Data Systems and Risk Analysis.

The following illustration shows the organization hierarchy for Fremont Corporation.

Fremont Corporation: Organization Hierarchy Example

Designing Organization Hierarchies to Facilitate Better Searching and Reporting

When you define organization hierarchies, create logical groupings of organizations that you would want to search by. This enables you to control the extent of the searches you perform by entering the name of organizations at different levels of the hierarchy. For example, if you define organizations by regions, you can perform searches by lower levels of a region, and then go up or down the hierarchy to see more or fewer resources.

The accuracy of your search results increases as you increase the granularity of your search criteria. For example, if you only define one organization for all of your resources, that organization will not be a factor in reducing your resource pool. You have to use other search criteria (such as job levels or competencies) to narrow down the field of search results.

In addition to searching, reporting also depends on a good organization hierarchy setup. You need to ensure the organization hierarchy supports the level of reporting that you want to do for one or many organizations rolled up.

If you want to perform resource searching and reporting across business groups, define a global organization hierarchy that contains all of the business groups and subordinate organizations in the hierarchy. When you perform searches, you can define a top level organization in the global hierarchy to search across business groups for project information. You can also use this global hierarchy for reporting if you want to view reports that compare project information across business groups.

There is no need to specify a global organization hierarchy if you do not want to search or do reporting across business groups. Each organization can have a business group specific organization hierarchy defined in their implementation options. By default, all searches start with the business group hierarchy that the user belongs in. You can always search in the organization hierarchies of other business groups. This setup prevents you from searching in more than one business group at a time, however.

Related Topics

Assigning Burdening Hierarchies

Business Groups

Security Groups

Security in Oracle Projects

Providing Data Across Business Groups

Case Study: Organization Change in Fremont Corporation

Organization Hierarchies, Oracle HRMS Enterprise and Workforce Management Guide

Assigning Burdening Hierarchies

To assign project burdening hierarchies, you follow the procedures described below:

To specify project burdening hierarchies

1. Select an Oracle Projects responsibility with access to the Organization window associated with the Business Group for which you are entering Legal Entities and Operating Units.

   Note: Perform these steps in the corresponding Oracle Human Resources windows if you have installed that application.

2. Navigate to the Organizations window (Setup > Human Resources > Organizations > Define).

3. Define an organization or query organizations that you defined as a business group. You must define the hierarchy before you designate it as the project burdening hierarchy.

Depending on your enterprise organization structure and business process, it is possible for the Project Burdening Hierarchy Version to be different from the Project/Task Organization Hierarchy Version, Expenditure/Event Organization Hierarchy Version, or Default Project Reporting Organization Hierarchy Version that you defined for any operating units associated with the business group. The Cost Distribution processes will not burden expenditures for expenditure organizations that are not in the Project Burdening Hierarchy.

Related Topics

Defining Organizations

Defining Organization Hierarchies

Locations

You define a location for each address your enterprise uses. Give each location a short name and then assign it to an individual organization or to an employee. A location is easier to type than a full address, especially if many employees or organizations use it. If several organizations are located at the same address, you assign the corresponding location to each organization.

For example, if WHQ is the location for World Headquarters and West is the location for a West coast office, you assign all organizations at World Headquarters the location WHQ, and all organizations at the West coast office the location West.

You can use locations for reporting purposes. For example, you might assign one location to your corporate headquarters and another location to your large branch office on the East coast. Both of these organizations may include several subordinate organizations. You can create custom reports using these locations, such as one that breaks down the total revenue by the location of a project-owning organization.

You can reuse previous locations or create new locations. Any user can access location information when prompted for a location anywhere within the application. However, you can add only city and states, not countries.

Example: Fremont Corporation Locations

Fremont Corporation's Oracle Projects implementation team defines the following locations:

• HQ: Fremont's corporate headquarters, where most of its organizations are located

• East: The East coast field office of the Fremont Construction business unit

• International: The International field office of the Fremont Construction business unit

The location details are shown in the following table:

Name	Description	City	State	Country
HQ	Corporate Headquarters	Bay Grove	CA	United States
East	Construction -- East coast field office	Boston	MA	United States
International	Construction -- International field office	Marseilles		France

Related Topics

Defining Organizations

Site Locations, Oracle HRMS Enterprise and Workforce Management Guide

Adding Operating Units

Many of the steps you perform to implement your first Oracle Projects operating unit define parameters and features that are shared across all operating units. To set up additional operating units, you only need to perform the steps that control parameters for an individual operating unit. Similarly, some Oracle Projects setup steps define parameters that are shared across operating units associated with the same business group. You need perform these steps only once for each business group.

For guidance on which steps in the Oracle Projects Implementation Checklist you must repeat for each operating unit, see: Implementation Steps.

If your implementation requires that you integrate Oracle Projects with other Oracle applications, you must set up the other applications for each operating unit that you want to integrate. For comprehensive implementation information for each product, refer to the corresponding product implementation instructions and Multiple Organizations in Oracle Applications.

If your organization structure includes multiple business groups, complete the setup for each business group before you perform the setup steps for the related operating units. For instructions on setting up business groups, see the Human Resources setup steps section in the Oracle Projects Foundation Implementation Checklists, Oracle Projects Implementation Guide.

If your organization uses cross charging and intercompany billing, see: Setting Up for Cross Charge Processing, Oracle Projects Implementation Guide, and the Oracle Projects Implementation Checklist, Oracle Projects Implementation Guide.

Implementation Steps

For each operating unit you want to add, perform the following steps:

1. Define implementation options

See: Implementation Options, Oracle Projects Implementation Guide.

Each operating unit has its own implementation options. The options determine how data is interfaced with other Oracle applications and controls cross-charging and internal billing across operating units.

Automatic Project Numbering. If you use automatic project numbering, note that project numbers (including project template numbers) are unique across operating units. If a value is entered for next project number, all operating units that use the automatic project numbering method will display the same number.

Automatic Invoice Numbering. Unlike project numbers, invoice numbers are unique within an operating unit, not across operating units. If you use automatic invoice numbering, the next invoice number is specific to the operating unit.

Note: If you are implementing Project Billing, the Invoice Batch Source field (under the Billing tabbed region) is required; Oracle Projects uses the batch source as a context value in the Invoice Transaction flexfield. The default is the Oracle Receivables batch source Project Invoices and two transaction types, PA Invoice and PA Credit Memo. For new operating units, the Receivables batch source Projects Invoices is replicated automatically.

2. Define PA periods

See: Defining GL and PA Periods, Oracle Projects Implementation Guide.

You define the PA periods you want to use in the calendar associated with your ledger. When the PA period type is defined for the operating unit, the system copies accounting periods from the calendar of the ledger. For more information on defining the period type and accounting periods, see the Oracle General Ledger Implementation Guide.

Each operating unit maintains its own PA period status. You use the Maintain PA Periods Status window to maintain the period status and the current reporting period. You can copy additional PA Periods from the calendar by choosing the Copy from GL button. Once a transaction is posted to a PA period from any of the operating units, you cannot change the period date range in the Calendar window.

Note: You must open and save a period before you can define it as the current reporting period.

3. Define cost rates for expenditure types

See: Defining Cost Rates for Expenditure Types, Oracle Projects Implementation Guide.

Expenditure types are set up once and are shared across all operating units. However, the cost rates for expenditure types are specific to each operating unit. Each operating unit must have cost rates for the expenditure types in which expenditures are expected to be incurred. The cost rates are defined in the functional currency of the ledger assigned to the operating unit.

4. Define usage cost rate overrides

See: Defining Usage Cost Rate Overrides,Oracle Projects Implementation Guide.

Non-labor resources are set up once and are shared across all operating units. For each of the non-labor resources that an operating unit may put in service, you must set up a cost rate for the associated expenditure type. If you want to have non-labor resources with different cost rates in different operating units, define usage cost rate overrides for organizations in the business group associated with an operating unit. The cost rates are defined in the functional currency of the ledger assigned to the operating unit.

5. Define labor costing overrides

See: Labor Costing Overrides, Oracle Projects Implementation Guide.

Employees are associated with a business group. An employee's work can be charged to any of the operating units that are associated with the employee's business group. If your business process allows an employee to work in a subset of these operating units, set up labor rates for each of the operating units in which the employee works. You can set up different labor rates for the same employee in different operating units.

6. Define bill rate schedules

See: Rate Schedule Definition, Oracle Projects Implementation Guide.

Bill rate schedules work similarly to cost rates. Each operating unit must have its own bill rates. You can have different bill rates for the same resource in different schedules of each operating unit. The bill rates in a bill rate schedule are denominated in the functional currency for the operating unit. For project billing, you can select the bill rate schedule only within the project operating unit. However, you can select any operating unit's bill rate schedule for a transfer price rule.

7. Define project types

See: Project Types, Oracle Projects Implementation Guide.

Set up project types for each operating unit. Each project type is specific to the operating unit and has it own attributes to control project processing by operating unit.

8. Define project templates

See: Defining Project Templates, Oracle Projects Implementation Guide.

Like project types and projects, project templates belong to a single operating unit. For each project type class, you must define at least one project template in order to define a project with that project type class. Project templates can only be maintained and copied within an operating unit. However, project template numbers are unique across operating units. A project template number cannot duplicate any project or project template number within the Oracle Projects installation.

9. Set up AutoAccounting for costs

AutoAccounting rules for costs are set up once for each chart of accounts. However, accounting rule assignments are specific to each operating unit. The multi-organization Replicate Seed Data process will replicate system-defined function transactions in each operating unit you set up. For each operating unit, you must enable cost function transactions and assign proper accounting rules for Oracle Projects to use when automatically generating your cost accounting entries.

Oracle Projects uses AutoAccounting to generate default accounts. If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Projects derives using AutoAccounting. For information about setting up AutoAccounting and Oracle Subledger Accounting for Oracle Projects, see: Accounting for Costs, Oracle Projects Implementation Guide.

Note: If you use SQL statement rules for your AutoAccounting or Account Generator, then use partitioned tables (ending in _ALL). Because accounting rules can depend on data elements across operating unit boundaries, using the _ALL tables maintains your ability to use the cross-charging feature supported by Oracle Projects in a multiple organization installation.

10. Set up AutoAccounting for revenue and billing

AutoAccounting rules for revenue and billing are set up once for each Chart of Accounts. However, accounting rule assignments are specific to each operating unit. The multi-organization Replicate Seed Data process will replicate system-defined function transactions in each operating unit you set up. For each operating unit, you must enable the revenue and billing function transactions and assign proper accounting rules for Oracle Projects to use when automatically generating your revenue and billing accounting entries.

Oracle Projects uses AutoAccounting to generate default accounts. If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Projects derives using AutoAccounting. For information about setting up AutoAccounting and Oracle Subledger Accounting for Oracle Projects, see: Accounting for Revenue and Billing, Oracle Projects Implementation Guide.

Note: If you use SQL statement rules for your AutoAccounting or Account Generator, then use partitioned tables (ending in _ALL).

11. Define indirect projects for cost collection

See: Accounting for Indirect Costs, Oracle Projects Implementation Guide.

Projects are owned by an operating unit. If you want to use Oracle Projects to track costs your operating unit incurs, including work that is not directly associated with project work, you can define as many indirect projects as you need to record indirect costs.

12. Specify profile option values

See: Profile Options in Oracle Projects, Oracle Projects Implementation Guide.

Profile options specify default values that affect system processes, system controls, and data entry. In a multi-organization environment, you can confine a profile option value to a specific operating unit by defining the profile options at the responsibility level. Review the following Oracle Projects profile options to determine if you want to define their values at the responsibility level.

• PA: Cross-Project User - Update

• PA: Cross-Project User - View

• PA: Debug Mode

• PA: Default Expenditure Organization in AP/PO

• PA: Default Public Sector

Additional Steps for Operating Units Associated With a New Business Group

You must perform the following implementation steps for each business group:

1. Define project burdening organization hierarchy

See: Assigning Burdening Hierarchies

Oracle Projects uses the project burdening hierarchy defined for each business group to compile burden schedules. Each business group must have a single version of the organization hierarchy designated as its project burdening hierarchy.

2. Define burden schedules

See: Burden Schedules, Oracle Projects Implementation Guide.

Set up and compile burden schedules for each business group. Burden schedules are shared among operating units associated with the same business group. If organization burden multipliers are not explicitly defined in the Define Burden Schedule window, they will use the next higher level organization in the Project Burdening Hierarchy defined for the business group as the default.

3. Define resource lists

See: Resources and Resource Lists, Oracle Projects Implementation Guide:

Set up resource lists for each business group. Resource lists are shared among operating units associated with the same business group. You can define a resource list by copying it from an existing resource list in the same business group.

Adding Organizations to the Project Burdening Hierarchy Version

If you add a new organization to the Project Burdening Hierarchy Version, you must do one of the following:

• add new burden multipliers for that organization in the appropriate burden schedules, or

• use the multipliers inherited from the parent organization as the burden multipliers for the organization

If you want to add burden multipliers to a particular schedule version for the organization, you need to compile the affected schedule version.

If you use the parent organization multipliers, you must submit the PRC: Add New Organization Burden Compiled Multipliers process. This process adds multipliers for this organization to all burden schedules versions for which you did not explicitly add multipliers.

If you do not run this process, you will encounter a rejection reason of 'Cannot find compiled multiplier' for transactions charged to this organization.

Case Study: Organization Change in Fremont Corporation

In this case study, we use Fremont Corporation to demonstrate how to use Oracle Projects to address organization changes.

In its original implementation, Fremont Corporation's organization hierarchy contained four organizations directly subordinate to its business group. The four organizations have several subordinate organizations. Following is an illustration of Fremont Corporation's initial organization hierarchy:

Fremont Corporation has one business group, the Fremont Corporation.

• Under the business group, there are four divisions: Administrative, Fremont Engineering, Fremont Construction, and Fremont Services.

• The Administrative division includes four organizations: Executive Office, Human Resources, Finance, and Information Services.

• The Fremont Engineering division includes four organizations: Electrical, Mechanical, Structural, and Environmental.

• The Fremont Construction division includes four organizations: West, Midwest, East, South, and International.

• The Fremont Services division includes two organizations: Data Systems and Risk Analysis

The following illustration shows the initial organization hierarchy for Fremont Corporation.

Fremont Corporation: Initial Organization Hierarchy

Due to the continued growth of its international construction business sector, Fremont Corporation sets up a separate organization for Europe, subordinate to the existing International organization, to manage its European construction projects. The new organization hierarchy is shown in the following illustration:

Fremont Corporation has one business group, the Fremont Corporation.

• Under the business group, there are four divisions: Administrative, Fremont Engineering, Fremont Construction, and Fremont Services.

• The Administrative division includes four organizations: Executive Office, Human Resources, Finance, and Information Services.

• The Fremont Engineering division includes four organizations: Electrical, Mechanical, Structural, and Environmental.

• The Fremont Construction division is divided into two subdivisions: U.S. and International. The U.S. subdivision contains four organizations: West, Midwest, East, and South. The International subdivision contains one organization: Europe.

• The Fremont Services division includes two organizations: Data Systems and Risk Analysis

The following illustration shows the new organization hierarchy for Fremont Corporation.

Fremont Corporation: New Organization Hierarchy

Business Assumptions

This case assumes there is no impact from the organization change on a multiple organizations architecture.

For information on multiple organization change, see Operating Units and Multiple Organizations.

Business Requirements

Fremont Corporation identifies the following requirements for the organization changes:

• The organization changes take effect on 22-Sep-97. This date begins the tenth month and last quarter of fiscal year 1997. See Defining PA Periods, Oracle Projects Implementation Guide.

• All active Europe projects and their corresponding tasks will be transferred and managed by the Europe organization. The rest of the international projects will still be owned by the International organization.

• Europe will get some resources transferred from International. Europe will also acquire additional resources. Europe will be a cost center that will incur project costs, generate project revenue, and maintain its own budget.

• Europe will have it own billing schedule with a higher international markup.

• Burden Schedules are standardized at Fremont Corporation, and will not require any changes.

• Fremont Construction customer invoices will continue to be processed and collected by Fremont Construction.

• In addition to obtaining reports at each organization level, Fremont Corporation also wants reports at the Fremont Construction level (total construction business) and at the U.S. and International organization levels.

Planning the Organization Change

Oracle Projects provides the flexibility to allow adjustments made to meet real world organization changes. You must plan the necessary setup changes and processes to implement the changes according to your business requirements. Careful planning and analysis will ensure your business objectives are met.

When to Make the Change

Oracle Projects enables you to track project data on both a PA period and GL period basis. To have a clear audit trail for reporting and analysis, most businesses choose a new fiscal month, quarter, or year to implement any organization changes. You must make the necessary setup changes on or after the effective date of the organization change. See: Setup Changes Required for an Organization Change.

In our example, Fremont Corporation chooses to have the organization change take effect on 22-Sep-97. Any impacted projects, tasks and transactions that were processed before the system setup changes took place, and whose transaction date is on or after 22-Sep-97 must be adjusted to reflect the organization changes. Following is a summary of actions that Fremont Corporation takes.

Before the Organization Change

Before the changeover date of 22-Sep-97, Fremont Corporation must analyze, plan and document procedures for performing the organization changes. They process project transactions as usual under the old organization setup.

To avoid adjustments, you can optionally delay processing transactions dated on or after the changeover date. However, you can use manual adjustments or the Oracle Projects Mass Update Batch process to adjust the transactions after they are processed.

On or After the Organization Change

Fremont Corporation will complete the following steps on or after the date of the organization change:

1. Process Transactions

   Complete normal steps to finish processing transactions that will post to months prior to Fremont Corporation's fiscal month 10 of 1997.

   Although not required by the system, you may want to perform steps to close the prior periods. This will prevent transactions from incorrectly posting to the prior GL or PA periods under the new organization setup.

2. Perform Setup Changes

   Perform the required changes in your Oracle Projects setup. See Setup Changes Required for an Organization Change.

3. Assign New Organization to Projects, Tasks, and Transactions

   Fremont Corporation must transfer some of the projects and tasks formerly associated with the International organization to the new Europe organization.

   They must also change transactions that were processed before the change, but that need to reflect the organization changes. This can be done by performing one or a combination of the following steps:

4. Manually update the project/task organization from International to Europe, using the Projects, Templates window. For an audit trail, Oracle Projects will create a mass update batch with a Manual prefixed name and Completed batch status.

5. Manually adjust transactions of affected projects or tasks that are on or after 22-Sep-97 to Europe.

6. Prepare the mass update batch. You can prepare the batch by using the Mass Update Batches window or through a customized process. Run the PRC: Mass Update Batch process. Resolve any errors encountered during the process. See: Mass Update for Projects and Tasks.

   The Mass Update Batch process will mark the affected expenditure items. You must manually adjust any outstanding events affected by the organization changes. You must also manually adjust any cost-based or event-based revenue or invoices affected by the organization change.

   After making the adjustments, you must run the appropriate cost, revenue and invoice processes. For more detail on revenue and invoice adjustments, see: Accruing Revenue for a Project, Oracle Project Billing User Guide and Invoicing a Project, Oracle Project Billing User Guide.

Setup Steps Required for an Organization Change

Some or all of the following implementation steps must be performed when you have an organization change.

Note: Several of the following steps are included in the Implementation Checklist. For more information about them, see the Oracle Projects Implementation Guide.

1. Define Organizations

• Define a new organization called Europe.

  • Enable the HR Organization classification to enable Europe to have employees

  • Enable the Expenditure/Event Organization classification so that Europe can incur project expenditures and have its own budgets and billing schedules.

  • Enable the Project/Task Owning Organization classification so that Europe can own projects.

  • Do not enable the Project invoice Collection Organization classification. Invoices for Europe are processed using transaction types associated with Fremont Construction.

• Define a new organization called U.S. No organization classifications are required for the U.S. organization.

2. Define the New Organization Hierarchy

Fremont Corporation must update the organization hierarchy version, according to the new hierarchy.

Organization Hierarchy Oracle Projects

Version Number 1

Because Fremont Corporation has chosen to standardize the organization hierarchy version for all of its project processing, it only needs to make adjustment to the organization hierarchy named Oracle Projects, and the organization hierarchy version number 1. If Fremont Corporation had originally set up different organization hierarchy versions to meet different business policies, procedures, and processes for its business, each organization hierarchy version would have required updating.

3. Assign a Project Burdening Hierarchy to the Business Group

Fremont Corporation will skip this step, because Fremont Corporation uses the same organization hierarchy version for project burdening that it uses for other business processes.

4. Define Employees

Transfer and add employees to the Europe organization.

5. Define Implementation Options

• If the organization change includes creating a new operating unit, implementation options required for a new operating unit must be set. See Adding Operating Units.

• If the Project/Task Owning Organization Hierarchy Branch of an operating unit will change as a result of the organization change, you must change the organization hierarchy /version and/or start organization assigned to the operating unit.

• If the Expenditure/Event Organization Hierarchy Branch will change, you must change the Expenditure/Event Organization Hierarchy Branch assigned to the operating unit.

• If the Default Reporting Organization Hierarchy Version will change, you must change the Reporting Organization Hierarchy Branch assigned to the operating unit.

Fremont Corporation can skip this step, since none of the above conditions are true for this organization change.

6. Define Cost Rates for Expenditure Types

Update existing expenditure types and add new expenditure types based on the organization change.

Fremont Corporation does not need to add new expenditure types for their organization change. They have already set up standardized expenditure types for the corporation.

7. Define Non-Labor Resources

Define non-labor resources for the new organization(s).

Fremont Corporation must update the non-labor resources PC and Minivan to add Europe as an additional owning organization, as shown in the following table:

Non-Labor Resource	Description	Expenditure Type	Organization
PC	PC on the HQ network	Computer Services	Europe
Minivan	Site visit minivan	Vehicle	Europe

8. Define Expenditure Type Cost Rates

Update rates for expenditure types and/or set up new expenditure type cost rates.

Fremont Corporation sets up higher expenditure cost rates for the expenditure type Computer Services, as shown in the following table, to cover the overall increased cost of supporting the Europe organization.

Expenditure Type	Unit of Measure	New Rate
Computer Services	Hours	10.00

9. Define Usage Cost Rate Overrides

Set up new usage cost rate overrides for the Europe organization.

Fremont Corporation sets up higher cost rates for minivans owned by the Europe organization, as shown in the following table.

Non-Labor Resource	Expenditure type	Organization	Usage Cost Rate Override
Minivan	Vehicle	Europe	60.00

10. Define Employee Rates

Define employee rates where required for changed rates and for new employees hired for the Europe organization.

11. Define Burden Schedules

Update and/or add new burden schedules based on the organization change.

Fremont Corporation does not need to define new burden schedules.

12. Define Bill Rate Schedules

Fremont Corporation must define a new bill rate schedule for the Europe organization, because Europe will have higher billing rates.

13. Define Resource Lists

Update resource lists that are affected by the organization changes. Add new organizations to the resource lists that group or maintain resource details by the organizations resource type.

14. Define Project Types

Set up new project types you will need, using the new defaults such as bill rate schedules and burden schedules.

15. Define Project Templates

Set up new project templates you will need, using new defaults such as project and task organizations.

16. Set Up AutoAccounting

Make changes to the AutoAccounting setup based on the organization change. Fremont Corporation must make the following updates to the lookup sets listed in the table below to take into account the new organization.

Lookup Set Name	Lookup Set Description	Segment Value: Organization	Segment Value: Company Code
Organization to Company	Map organization to the appropriate company code	Europe	03
Organization to Cost Center	Map organization to the appropriate cost center code	Europe	306

17. Modify Client Extensions

Modify any client extensions affected by the change.