Understanding Project-Related Control Data

Project Costing uses integration templates to share projects across multiple business units in PeopleSoft Asset Management, Purchasing, and General Ledger. For example, if you create an integration template that points to multiple general ledger business units, you can share a project across those specific business units. Integration templates also establish business units that are assigned to transactions by default.

You must assign an integration template to each new project. For example, if a company has an aerospace division and a utilities division, aerospace projects may use one general ledger business unit and utilities projects may use another general ledger business unit. Therefore, you will set up two integration templates—one to define the business unit integration for aerospace projects and one to define the business unit integration for utilities projects.

Each project integration template contains a specific set of general ledger business units. Integration templates provide the flexibility to define the integration between project business units and general ledger business units that best fit the organization's needs. You can set up the project and general ledger integration so that:

• One project business unit can post to many general ledger business units.

• Many project business units can post to a single general ledger business unit.

• Each project business unit can post to a different general ledger business unit.

The system also uses integration templates to control access to general ledger business units. You can post transactions for a project only to a general ledger business unit that is specified in the integration template that is assigned to the project. The same control applies to purchasing business units. You can create requisitions in PeopleSoft Purchasing for a project only if the purchasing business unit is defined on the integration template for the project.

The system uses project types to categorize projects for reporting and analysis. Additionally, you can assign a default rate set or rate plan to a project type for specific business units. When you create a new project and specify the project type, the system automatically attaches the default rate set or rate plan that is associated with the project type and business unit combination.

Using project types is optional.

Project Costing uses two statuses to convey where a project is in its life cycle—project status and processing status:

• Status field (PROJECT_STATUS)

  This required, user-defined field identifies the conditions that you want to track for projects and activities. The status also defines project events, such as conditional changes that require approval.

  You can define status types or use the system-delivered status types.

• Processing Status field (PROCESSING_STATUS)

  This system-defined field is used by the system to restrict incoming transactions. For example, you can charge cost transactions from feeder systems to projects with an active processing status but not to projects with a pending processing status.

  Valid processing status values are Pending, Active, Inactive, and Template. You map the user-defined status types to any system-defined processing status except the Template processing status. When you update a project status, the system automatically updates the processing status based on this mapping. You cannot change the processing status of a project directly.

You can map these system-defined processing status types to project status types:

• Active

• Pending

• Inactive

This table lists the status types that Project Costing delivers as sample data and their mappings to processing status types:

Every project status must map to a processing status. You can modify project status types and the delivered mappings, but you must not delete or modify the delivered processing statuses.

Process Flow

This diagram shows the process flow to set up project and processing statuses and to update a project status:

The diagram illustrates that an administrator sets up project statuses, links the project status to a processing status, optionally sets up project types, and optionally sets up project type status paths. Then a project manager creates projects and manually updates the project status.

After you update the project status, the system:

1. Determines if the corresponding processing status is a valid change based on the previous processing status.

   The processing status:

   • Can change from Active to Active.

   • Can change from Active to Inactive.

   • Can change from Inactive to Inactive.

   • Can change from Inactive to Active.

   • Can change from Pending to Pending.

   • Can change from Pending to Active.

   • Can change from Pending to Inactive.

   • Can not change from Active to Pending.

   • Can not change from Inactive to Pending.

2. Determines if the project status effective date is current or future-dated.

   An Application Engine process monitors project status effective dates and updates the processing status as necessary.

3. Determines if a processing status change is valid.

   If the change is not valid, an error message appears.

4. Determines if a project type status map exists for the project type.

   If a project type status map exists, the system determines if the project status change is valid based on the project type status path for that project type.

5. Determines if a project event is defined for this project status change.

   If a project event is defined, the system triggers approval workflow.

6. Updates project status and processing status.

Project type status paths combine project types and project status types to control the status progression through the life cycle of a project and activity. You can define custom project status paths for each project type and business unit combination.

For example, assume that you set up a project type status path for the project type of R&D (research and development) to manage the project life cycle. The status progression for this project type is:

1. Proposed

2. Budgeted

3. Active or Closed

4. Closed

In this example, users can change an R&D project from a proposed status only to a budgeted status. In other words, you cannot approve a project until it has been budgeted. You can change an R&D project from a budgeted status to an active status if the budget is approved, or to a closed status if the budget is not approved. When the R&D project is complete, you can change the status from active to closed. This project type status path restricts users from changing a closed project to any other status. In this way, you prevent users from reopening projects that were previously closed.

Select the Use Status Path check box on the Project Types page to use a project type status path for a specific project type. Use the Project Type Status Path page to define status paths.

After the system determines if a project status and the corresponding processing status are valid changes, the system determines if the project type status path is valid.

When you enter dates in a project schedule, the phase of the project that those dates represent can be useful information. For example, for a phase type of Clean Up, you can enter a begin cleanup date and an end cleanup date in the project schedule to track the time that is spent specifically on the Clean Up phase. Using phase types is optional.

Project events are changes in the status of a project or an activity. For example, you can define a change in project status from Proposed to Approved as a project event that requires approval. A project event can be a change in project status between two consecutive status types, such as Proposed and Approved, or two nonconsecutive status types, such as Proposed and Closed. You must define project status types before you define project events. Using project events is optional.