Overview of Implementing Oracle Projects

This chapter contains an overview of the implementation process.

This chapter covers the following topics:

• Planning Your Implementation
• Overview of Setting Up Oracle Projects
• Oracle Projects Implementation Checklist
• About Fremont Corporation: An Example of Setting Up Oracle Projects

Planning Your Implementation

As you plan your implementation of Oracle Projects, we recommend that you consider the implementation issues discussed in this section. Implementing a core system such as Oracle Projects is a complex and lengthy task. By carefully planning your implementation, you can save valuable time and prevent errors.

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

Your Implementation Team

Your implementation team creates and executes the implementation plan and makes most of the implementation decisions. Your implementation team makes many important decisions, from re-engineering your business procedures, to preparing for conversion, to determining your system requirements.

Your implementation team should be very broad-based, with representatives from your MIS, accounting, and project management departments. Ideally, the team is made up of staff who can dedicate a significant amount of time to implementation issues.

You should also appoint one member of your implementation team to head the implementation, facilitate resolution of issues, and act as liaison between your organization and Oracle Worldwide Customer Support and Oracle Consulting Services.

Implementation Decisions

Your implementation team should re-examine all your business procedures in light of the functionality in Oracle Projects.

Review Your Business Procedures

The terminology your business uses, your organization structure, your accounting practices, how you classify expenditures, and your reporting policies are just a few issues that will influence many decisions you make about your implementation of Oracle Projects.

Preparing Your Implementation Data

Your implementation team must determine how to configure the features in Oracle Projects.

As you determine your implementation data, you must keep AutoAccounting in mind. The AutoAccounting feature in Oracle Projects derives values for account combinations based on project information for all accounting transactions in Oracle Projects. Consequently, the way you organize your chart of accounts affects your implementation data. For example, if you charge several expense accounts for varied expenditures such as meals, travel and lodging, and airfare, then you need to implement an expenditure type that corresponds to each expense account. You can use most of the implementation data that you define for Oracle Projects as inputs to the AutoAccounting rules that you define.

Related Topics

Overview of Setting Up Oracle Projects

Data Conversion

Since data conversion from your existing systems is typically the most error-prone area of implementation, we recommend that your implementation team invest considerable time planning and testing it.

We recommend that you test your data conversion program carefully using sample data before you migrate to Oracle Projects. After conversion, you should verify the functionality of your data.

Data Migration and Reporting Using iSetup

After you implement Oracle Projects on an instance, you can use iSetup to extract this implementation data from the source instance and load it to other new target instances. To do this, add the iSetup responsibility to the user logging into the Oracle application instance.

Create a selection set using the Projects Setup predefined selection set template and use this selection set to extract implementation data from the named source instance. Because Oracle Projects APIs are standalone APIs, you can select to run one or more APIs from the available set of APIs for the selection set that you create. Oracle Projects provides filters for extracting and transforming data using iSetup.

During the load, if an API is enabled for update, the load process overwrites the existing record in the target instance with the extracted record. If the API does not allow update of existing records in the target instance, Oracle iSetup displays an error message. In addition, if the API has dependencies and the corresponding data is not available in the target instance, the API does not create a new record in the target instance. In the case of Planning Resource List and Resource Breakdown Structure, if the dependency record is not available in the target instance, the API does not create any of the records in the load extract.

The following table lists the available APIs, their dependencies, and their update capabilities.

API Name	Oracle Projects Dependencies	Supports Update
Agreement Types	None	Yes
Expenditure Categories	None	Yes
Transaction Sources	None	Yes
Cost Bases	None	Yes
Event Types	None	No
Invoice Formats	None	No
Labor Costing Rules	Expenditure types - PA_PROJECT_EXPENDITURE_TYPES	No
Expenditure Types	Expenditure Categories - PA_EXPENDITURE_CATEGORIES	No
Burden Cost Codes	Expenditure Types - PA_PROJECT_EXPENDITURE_TYPES	Yes
Rate Schedules	Expenditure Types - PA_PROJECT_EXPENDITURE_TYPES Non Labor Resources - PA_NON_LABOR_RESOURCES	No
Non Labor Resources	Expenditure Types - PA_PROJECT_EXPENDITURE_TYPES	No
Labor Costing Overrides - PA_LABOR_COSTING_OVERRIDES	Labor Costing Rules - PA_LABOR_COSTING_RULES Rate Schedules - PA_RATE_SCHEDULES	No
Organization Labor Costing Rules - PA_ORGANIZATION_LABOR_COSTING_RULES	Labor Costing Rules - PA_LABOR_COSTING_RULES Rate Schedules - PA_RATE_SCHEDULES Expenditure Types - PA_PROJECT_EXPENDITURE_TYPES	No
Burden Structures - PA_BURDEN_STRUCTURES	Cost bases - PA_COST_BASES Cost Codes - PA_COST_CODES Expenditure types - PA_PROJECT_EXPENDITURE_TYPES	No
Burden Schedules - PA_BURDEN_SCHEDULES	Burden Structures - PA_BURDEN_STRUCTURES Cost Codes - PA_COST_CODES	No
Resource Breakdown Structures - PA_RESOURCE_BREAKDOWN_STRUCTURES	Non Labor Resources - PA_NON_LABOR_RESOURCES Event Types - PA_EVENT_TYPES Expenditure Types - PA_PROJECT_EXPENDITURE_TYPES Expenditure categories - PA_EXPENDITURE_CATEGORIES	No
Planning Resource Lists - PA_PLANNING_RESOURCE_LISTS	Non Labor Resources - PA_NON_LABOR_RESOURCES Event Types - PA_EVENT_TYPES Expenditure Types - PA_PROJECT_EXPENDITURE_TYPES Expenditure categories - PA_EXPENDITURE_CATEGORIES	No

You can reuse the extracts that you create to load multiple target instances or to produce reports. These reports can be standard reports for an extract or comparison reports between extracts. For more information on using iSetup, see the Oracle iSetup User Guide.

User Training

Plan training for all members of your company that will use Oracle Projects. You should include employees who interact directly with the software or who review the data that is reported from the system. The training may include steps in how to use the system to perform specific tasks and explanations of any new business policies that you may institute as a consequence of implementing Oracle Projects.

System Testing

Plan and execute extensive system testing of your enterprise solution - including the Oracle Applications and any systems that interface with the applications. Your system test environment should be as similar to your production system as possible. After you convert your data for testing, assign users to test the functions that they currently or will perform. Provide your testers with the appropriate hardware resources so you can accurately judge performance issues.

Overview of Setting Up Oracle Projects

To help you implement Oracle Projects, this book walks you through a sample implementation for Fremont Corporation, a fictitious engineering, construction, and consulting firm. For each implementation step, we explain how Fremont implements its own policy, practice, or procedure in Oracle Projects. By studying Fremont's implementation, you can learn more about how to implement your own policies, practices, and procedures using Oracle Projects. See: About Fremont Corporation: An Example of Setting Up Oracle Projects.

Setting up Underlying Oracle Applications Technology

The setup steps in this chapter tell you how to implement the parts of Oracle Applications specific to Oracle Projects.

You need to complete several other setup steps, including:

• performing system-wide setup tasks such as configuring concurrent managers and printers

• managing data security, which includes setting up responsibilities to allow access to a specific set of business data and complete a specific set of transactions, and assigning individual users to one or more of these responsibilities

For more information, see: Oracle Applications System Administrator's Guide.

Also, if your implementation uses Oracle Workflow to manage project or budget status changes, or to derive the Project Related Supplier Invoice Account via the Account Generator, you need to set up Oracle Workflow.

For more information, see: Oracle Workflow User's Guide.

Oracle Projects Implementation Checklist

The implementation checklist is made up of several checklists, one for each of the products in the Oracle Projects solution, as listed below:

• Oracle Project Foundation

• Oracle Project Costing

• Oracle Project Billing

• Oracle Project Resource Management

• Oracle Project Management

• Oracle Project Portfolio Analysis

• Oracle Project Collaboration

You can combine each product checklist with others, based on your implementation.

Overview of the Oracle Projects Implementation Checklist

Following are some guidelines for using the implementation checklist.

Perform Steps in Order

Many of the implementation steps use information you define in previous steps, you should perform the steps in the order listed.

Shared Data

The implementation checklist summarizes each of the steps you follow to implement Oracle Projects. It includes setup steps for data that may be shared with other Oracle Applications but is required by Oracle Projects. If you have already defined this information when you implemented other Oracle Applications, you can skip those steps. This shared data includes:

• Ledger

• Employees and Organizations

• Customers

Subledger Accounting

Oracle Projects uses AutoAccounting to create default accounts for project costs that it sends to Oracle Subledger Accounting. Oracle Projects provides predefined setup in Oracle Subledger Accounting to accept the default accounts from Oracle Projects and transfer them to Oracle General Ledger without change. You have the option of defining your detailed accounting rules for Oracle Projects in Oracle Subledger Accounting. 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.

If you set up your own rules in Oracle Subledger Accounting, you must still set up AutoAccounting so that Oracle Projects can determine valid default accounts. The AutoAccounting setup enables processes, such as processes that distribute costs and generate accounting events, to determine the default accounts that Oracle Projects sends to Oracle Subledger Accounting.

Oracle Subledger Accounting derives values for account combinations based on project information. You can use most of the implementation data that you define for Oracle Projects as sources in Oracle Subledger Accounting. Sources are pieces of information that the process PRC: Create Accounting uses to create journal entries. Oracle Projects provides over 300 sources that you can use to determine and describe accounting entries. Examples of predefined sources include expenditure category, project type, task service type, and project organization.

AutoAccounting

As you determine your implementation data, you must keep AutoAccounting in mind. The AutoAccounting feature in Oracle Projects derives values for account combinations based on project information for all accounting transactions in Oracle Projects. Consequently, the way you organize your chart of accounts affects your implementation data. For example, if you charge several expense accounts for varied expenditures such as meals, travel and lodging, and airfare, then you need to implement an expenditure type that corresponds to each expense account. You can use most of the implementation data that you define for Oracle Projects as inputs to the AutoAccounting rules that you define.

Implementation Listings

After you complete most implementation steps, you can submit reports to review your work and confirm that you have successfully completed the step. For example, after you complete entering Agreement types, you can submit IMP: Agreement Types. See: Implementation Listings, Oracle Projects Fundamentals.

Checklist Sections

Each checklist is grouped first by product and second by function, so that you can implement your licensed product and the specific features that are needed for your business without having to implement the entire suite or implement unneeded functionality.

Product Setup Checklists

The product setup checklists are organized by area of functionality. The Required column indicates if the step is required for use of the product. The Optional column indicates if the step is optional for use of the product.

Feature Setup Checklists

The feature setup checklists are organized by feature within each product. The Required column indicates if the step is required for use of each feature. The Optional column indicates if the step is optional for use of each feature.

In addition, the Oracle Project Foundation checklists indicate, in the Required and Optional columns, the product or products for which the step is either required or optional, or All if all products in the Oracle Projects Suite are applicable.

Steps for Integrating Oracle Projects with Other Oracle Applications

Some of the steps in the implementation checklists are performed in other Oracle Applications, and affect the integration of Oracle Projects with those applications. You should understand the implications of integration with Oracle Projects as you perform these setup steps for other Oracle Applications. See the Setup chapter of each product's User Guide for comprehensive implementation information for the product.

How to Use the Implementation Checklist

When it comes to implementing Oracle Projects, each business has different needs. Just as Oracle Projects lets you tailor project requirements to fit your business needs, the sections describing the setups of Oracle Projects are designed to be equally flexible. Here are some suggested ways to use these sections.

Use it as a Step-by-Step Implementation Guide

This guide gives you step-by-step instructions on how to implement Oracle Projects. Each step explains what other steps you should complete first, what the step accomplishes, and the mechanics of the step. After you plan your implementation, simply follow the steps and enter your business policies, procedures, and requirements using Oracle Projects forms.

Each step is numbered to indicate (1) the product, (2) whether the step is part of the product setup or feature setup, and (3) the step sequence. For example, step PJF-P1.1 is step 1.1 in the product setup for Oracle Project Foundation. Step PJB-F1.1 is step 1.1 in the feature setup for Oracle Project Billing.

Use It as a Tutorial

You can also use this guide as a learning aid by following Fremont Corporation's Oracle Projects implementation. You can learn the mechanics of implementation and get something tangible when you finish-an Oracle Projects system with which you can experiment.

Use it as a Springboard to Plan Your Implementation

If you follow Fremont Corporation's implementation, you will have a projects system that meets Fremont Corporation's requirements, which may differ from your own. To design your own implementation plan, read through the examples and look for requirements that are similar to or different from your project needs. By studying Fremont Corporation's implementation, you can learn more about how to implement your own policies, practices, and procedures using Oracle Projects.

Effective Dates

Most setup windows have fields for effective dates, which are the dates during which the item you are defining will be active and will appear on a list of values.

The From effective date is required, and the system usually defaults the system date in that field. The To effective date is usually optional; you can leave this field blank if you want the item you are defining to be active indefinitely.

Date ranges are inclusive; an item becomes active on the From date and remains active through the end of the To date.

If you want to inactivate an item in the future, you can enter that future date in the To field.

For example, suppose you decide that you will no longer classify any projects as "Market Development" after the end of your calendar year. You set the Effective Date: To field to 31-DEC-2001, which prevents this classification code from appearing on lists of values, and prevents you from entering this classification code after December 31, 2001.

Similarly, you can prevent your employees from recording verbal payment agreements, effective tomorrow, by entering today's date in the Effective Date: To field for the agreement type "Verbal."

You can also use effective dates to record information that changes over time. For example, if you alter the bill rate for an employee on a specific date, you can enter the new bill rates and use the Effective Date fields to ensure that the old and the new bill rates are used as appropriate.

About Fremont Corporation: An Example of Setting Up Oracle Projects

Fremont Corporation is a fictitious company based in Bay Grove, California, that provides engineering, construction, and services contracting to a wide variety of domestic and international customers. It consists of four divisions: Administration, Engineering, Construction, and Services.

These divisions are further divided into a number of groups: For example, Administration has four groups: the Executive office, Human Resources, Finance, and Information Services.

Fremont Corporation: Organization Hierarchy

To integrate its accounting needs, Fremont Corporation implements other Oracle Applications products such as Oracle General Ledger, Oracle Receivables, Oracle Purchasing, Oracle Payables, and Oracle Assets.

Fremont Corporation decides to implement Oracle Projects for each division and begins by forming an implementation team. This team, made up of managers who understand Fremont Corporation's accounting and project management practices, decides how Fremont Corporation should implement Oracle Projects to best suit the company's business needs. They also define the policies, procedures, and requirements needed to complete the implementation.

Throughout this guide, whenever we discuss a particular aspect of implementation, we discuss how Fremont Corporation's implementation team chooses to implement Oracle Projects. Most of the examples are located at the end of an implementation step.

Note: Fremont Corporation may not have implemented all of the features available in this release of Oracle Projects.