Understanding Integration Between PeopleSoft Project Costing and PeopleSoft Commitment Control
Commitment Control is an optional feature of Oracle's PeopleSoft Financial Management Solutions, Enterprise Service Automation, and Supply Chain Management product lines. It enables you to control expenditures against predefined, authorized cost, or revenue budgets.
This topic discusses:
Setup requirements.
Integration process flow.
Project Costing to Commitment Control process.
Commitment Control to Project Costing process.
Budget checking errors and exceptions.
Security.
Note: This topic is supplemental to PeopleSoft Commitment Control and provides information about the integration between PeopleSoft Project Costing and PeopleSoft Commitment Control. Refer to Integration of Commitment Control with PeopleSoft Applicationsfor complete information about PeopleSoft Commitment Control functionality.
After you enable PeopleSoft Project Costing and PeopleSoft General Ledger for PeopleSoft Commitment Control on the Installation Options - Installed Products page, complete the steps to configure Commitment Control for integration with Project Costing.
The Understanding Basic Commitment Control Setup and Understanding General Ledger Business Units and Options topics discuss the steps required to configure those systems to integrate with PeopleSoft Project Costing, such as setting up basic Commitment Control options, source transaction types, and security.
Complete these steps to configure PeopleSoft Project Costing to integrate with PeopleSoft Commitment Control:
Set up integration templates to integrate with the appropriate general ledger (GL) business unit.
Select the Primary Ledger Business Unit check box on the Integration Templates - General Ledger Integration page to designate the primary GL business unit to use for budget creation and budget checking when this integration template is specified on the project.
Designate at the installation level the analysis groups that contain the analysis types to use to create revenue and expense budgets in PeopleSoft Project Costing.
You can override the budget analysis group at the project level.
At the set ID level, designate the analysis types that identify the transactions that must be budget checked before they are sent to the Project Transaction table (PROJ_RESOURCE).
Map the relationship between the source transaction definition and transactions in PeopleSoft Project Costing by using the Commitment Control Amount Type field on the Analysis Types Page. PeopleSoft General Ledger delivers two source transaction definitions for PeopleSoft Project Costing: PC_JOURNAL (used for both cost and revenue transaction rows) and PC_BUDGET (used to create budgets).
Note: You cannot disable Commitment Control for specific projects or processes.
The integration process flow begins with the creation of a budget in PeopleSoft Project Costing. Project budget rows and actual cost transactions can originate from several sources, such as:
Creating a budget plan and details in PeopleSoft Project Costing.
Adding actual cost transactions on the Add Transactions page in PeopleSoft Project Costing.
Importing budget rows from PeopleSoft Grants.
Importing budget rows and actual cost transactions from Microsoft Project.
Importing budget rows from PeopleSoft Planning and Budgeting.
Running the Funds Distribution process, see Understanding Funds Distribution
For more information about budgeting project costs and revenue, see Understanding Project Cost and Revenue Budgets.
Several different application engine processes play a key role in integrating PeopleSoft Project Costing and Commitment Control. The budget rows in PeopleSoft Project Costing are staged in the project transaction interface table (INTFC_PROJ_RES) until the Load Third-Party Transactions (PC_INTFEDIT) application engine process determines which rows need to be budget checked in Commitment Control. The Load Third-Party Transactions process triggers the Project Costing to Commitment Control Application Engine (PC_TO_KK) process to send budget rows and cost transactions that require budget checking to Commitment Control. The Project Costing to Commitment Control process triggers the Budget Processor (FS_BP) application engine process to budget check the transactions against the Commitment Control budget. If the available budget amount is not sufficient or the transaction receives some other budget-related exception, the budget processor records errors and exceptions are logged in the system. Finally, the Project Costing to Commitment Control process updates the project transaction interface table with the Commitment Control distribution status of error or posted. After the transaction rows successfully post to Commitment Control and the project transaction table, the system deletes the rows from the project transaction interface table.
The following diagram shows the processing flow for the Project Costing to Commitment Control process, part 1:
![Project Costing to Commitment Control process flow (1 of 2)](img/i2a517932n-7363.png)
The following diagram shows the processing flow for the Project Costing to Commitment Control process, part 2:
![Project Costing to Commitment Control process flow (2 of 2)](img/i2a517932n-7353.png)
The Project Costing to Commitment Control process:
Loads Project Costing Commitment Control rows from the Project Transaction Interface table to the Commitment Control Header (PC_KK_HDR) and Commitment Control Line (PC_KK_LN) staging tables.
Creates transaction IDs that the system uses to identify rows that it posts to the Project Transaction table.
You can view transaction IDs in the Project Details tab of the Project Budget Periods - Adjust Budget Periods page.
Checks budget entry or adjustment security.
Based on the budget definition, sends only defined ChartField data to Commitment Control and retains the budget detail data in PeopleSoft Project Costing.
When you send a new budget from PeopleSoft Project Costing to Commitment Control, the Project Costing to Commitment Control process adds the project to the Control ChartField page in Commitment Control when Project is specified as the control ChartField in the budget definition.
Converts the currencies of the project transaction amounts to the base currency of the general ledger business unit that is integrating with PeopleSoft Project Costing.
Calls the Commitment Control Budget Processor.
Updates rows in the Project Transaction Interface table with either a Posted or an Error Commitment Control distribution status and budget header status after the Budget Processor completes.
Creates journal IDs that appear on the Commitment Control tab of the Project Budget Periods - Adjust Budget Periods page after transactions successfully post to Commitment Control tables.
The Commitment Control transactions in the Project Transaction Interface table serve as PeopleSoft Project Costing journal entries. The journal ID acts as a link so you can drill down to the Commitment Control Budget Details page.
The budget period is a required field in the budget journal. For budget rows that originate in PeopleSoft Grants, the Project Costing to Commitment Control process derives the budget period from the calendar ID on the Keys and Translations page in Commitment Control based on the accounting dates in the Project Transaction table. For budget rows that originate in Projects Budgeting, the budget period is based on the budget plan calendar.
The Project Costing to Commitment Control process does not create fund source allocations.
For more information about Commitment Control Security, see Understanding Commitment Control Security.
Use the Commitment Control to Project Costing Application Engine process (PC_KK_TO_PC) to post budget transactions in PeopleSoft Project Costing that you enter directly into Commitment Control. Rows are eligible to post in Project Costing if both of these conditions exist:
The Project Costing distribution status of the journal line is N (new).
The ledger group type is either expenses or revenue.
After you post budget journals directly into Commitment Control, if Projects Budgeting is enabled at the installation level and you run the Commitment Control to Project Costing process, the system:
Populates the Project Transaction Interface table.
Triggers the Budget Loader Application Engine process (PC_BUDGET_IN) that populates the Project Budgeting tables (PC_BUD_PLAN, PC_BUD_ITEM, and PC_BUD_DETAIL).
Updates the Project Costing Distribution Status field (PC_DISTRIB_STATUS) value to D (distributed) on the Commitment Control Budget Journal Line table (KK_BUDGET_LN).
If you create a budget journal in Commitment Control and run the Commitment Control to Project Costing process and if Projects Budgeting is enabled at the installation level and no current active budget plan exists for that project, then the system:
Modifies the Project Costing Distribution Status field value of the journal row to D (distributed).
Creates a budget plan in PeopleSoft Project Costing with an active status.
For example, assume that you post Journal A and Journal B to Commitment Control. Both journals have identical ChartField values. The Commitment Control to Project Costing process creates one active budget plan that contains both journals.
If you subsequently unpost the budget journal in Commitment Control and run the Commitment Control to Project Costing process, the system:
Resets the Project Costing Distribution Status field value for the journal row back to N (new) if the original Project Costing Distribution Status field for the row was D.
Modifies the status of the existing budget plan to Inactive.
Creates a new budget plan with an active status that represents the reversal of the previous budget plan.
The new budget plan contains the same amounts as the previous plan but with the multiplier signs reversed.
Sends the new budget rows to the Project Transaction Interface table and Project Budgeting tables.
For example, assume that you post Journal A to Commitment Control and run the Commitment Control to Project Costing process. The process creates Budget Plan A as the active budget plan. Then you unpost Journal A in Commitment Control and run the Commitment Control to Project Costing process. The system changes the status of Budget Plan A to Inactive and creates Budget Plan B as the active budget plan, which represents the reversal of Budget Plan A.
If you create a budget journal in Commitment Control and run the Commitment Control to Project Costing process and if Projects Budgeting is enabled at the installation level and an active budget plan already exists in PeopleSoft Project Costing, then the system:
Modifies the status of the existing budget plan in PeopleSoft Project Costing to Inactive.
Creates a new budget plan in PeopleSoft Project Costing with an active status.
Sends the new budget rows to the Project Transaction Interface table and Project Budgeting tables.
Modifies the Project Costing Distribution Status field value for the journal row to D.
For example, assume that you post Journal A to Commitment Control and run the Commitment Control to Project Costing process. The process creates Budget Plan A as the active budget plan. Then you post Journal B and run the Commitment Control to Project Costing process. The system changes the status of Budget Plan A to Inactive, and creates Budget Plan B as the active budget plan.
You must define the project ID, activity ID, and Project Costing business unit as key ChartFields if you create budgets directly in Commitment Control and send them to Project Costing by using the Commitment Control to Project Costing process.
The Commitment Control to Project Costing process uses the analysis groups for the revenue budget and the cost budget that are specified on the Project Costing Definition page for the project. The process uses the first analysis type listed in the appropriate analysis group. For example, assume that you use the RBUD (Revenue Budget Group) analysis group for revenue budgets and the BUD (Budgets) analysis group for cost budgets. The analysis type RB1 (Revenue Budget 1) is listed first in the RBUD analysis group. Therefore, the process uses RB1 to post revenue budgets to the budget plan and the Project Transaction table.
When you generate a budget plan by using the Commitment Control to Project Costing process, the budget item default value is Other.
Note: If you create a budget journal in Commitment Control and Projects Budgeting is enabled at the installation level, you cannot change the default budget item in the project budget. In this way the system prevents you from changing the budget item from Other to another value, which would result in changing the ChartField values to correspond to the new budget item.
If you create budgets in PeopleSoft Project Costing, you must also adjust the budgets in Project Costing.
If you create a new budget journal in Commitment Control and Projects Budgeting is not enabled at the installation level, the Commitment Control to Project Costing process sends transaction rows to the Project Transaction Interface table and does not create a budget plan.
If the Commitment Control Budget Processor encounters an error, the system stores the transaction in the Commitment Control Transaction Exceptions table (KK_EXCPTN_TBL) and updates the row in the Project Transaction Interface table with a Commitment Control distribution status and budget header status of Error. Use the Review Commitment Control page to correct the errors and:
Drill to the source of the transactions.
Access the Commitment Control PC (Project Costing) Budget Exceptions page.
Access the Commitment Control PC Line Exceptions page.
Access the PeopleSoft Project Costing Budget Plan page for the project.
Resubmit transactions to Commitment Control for a specific interface ID.
PeopleSoft Project Costing uses the Commitment Control Budget Entry or Adjustment security event to enable you to restrict entry of a budget amount to a limited set of users.
Additionally, you can restrict users to specific budgets by using ChartField values on the Commitment Control Security Field Setup page.
The system records security errors in the Project Transaction Interface table just as it does with budget checking errors. You can view security errors on the Review Commitment Control page.
For more information about Commitment Control security, see Understanding Commitment Control Security.