Approval Events and Actions

The first step in the approval process is to identify the first person to approve the transaction. This person is based on the Approval Process definition. If the system identifies this person, the system sends a notification indicating that there is a reported time, payable time, or overtime waiting for approval. The approver has the option to:

• Approve the time request. The system sends a notification to the next person in the approval process, if one is indicated.

• Deny the time request. The system terminates the approval process. The originator of the time request receives a notification indicating that the time request has been denied.

• Push back the time request. The originator of the time request receives a notification indicating that the time request needs their attention.

  Note:

  TL_UTILITY app package has two classes one under UserUtilities and the other for Web clock data. The package are called GetApproversByTLSecurity and GetApproversByDeptSecurity.

  All Time and Labor delivered approval definitions contain one step. The push back always goes back to the originator in Time and Labor.

Approval Definition and Approval Flow

The routing path of an approval request is be based on the approval stages, paths, and steps. These elements make up the Time and Labor process definitions, which are used for Time and Labor approvals. The process definition dictates:

1. How the approval request proceeds from approver to approver.

2. How many approvers must approve a request before it is routed to the next approver.

3. If an approval request carried out in a parallel or sequential manner.

The following table describes the requirements and differences between the Time and Labor approvals definitions:

Definition ID	Approval Routing	Approver User List	Final Approval Status
TLByDeptManager	One stage, one path, and one step.	TLByDeptManager (assigned at step 1)	Approval by the specified manager required before the status of the request is Approved.
TLByPosnDeptMgr	One stage, one path, and one step.	TLByPosnDeptMgr (assigned at step 1)	Approval by the specified manager required before the status of the request is Approved.
TLByPosnSupervisor	One stage, one path, and one step.	TLByPosnSupervisor (assigned at step 1)	Approval by the specified supervisor required before the status of the request is Approved.
TLByPosMgmt	One stage, one path, and one step.	TLByPosMgmt (assigned at step 1)	Approval by PosMgmt required before the status of the request is Approved.
TLBySupervisorID	One stage, one path, and one step.	TLBySupervisorID (assigned at step 1)	Approval by the specified supervisor required before the status of the request is Approved.
TLGroupSingleStageALL	One stage, with two parallel paths that have one step in each path.	TLUserList1 (assigned at path 1/ step 1) and TLUserList2 (assigned at path 2/ step 1)	All approvers on path 1/ step 1 and all approvers on path 2/ step 1 must approve the request, before the status of the request is Approved. Note: The approvers on path 2/ step 1 can approve the request at the same time as the approvers on path 1/ step 1.
TLGroupMultiStageSOME	Two sequential stages, each with one path and one step.	TLUserList1 (assigned at stage 1/ path 1/ step 1) and TLUserList2 (assigned at stage 2/ path 1/ step 1)	Some approvers on stage 1/ path 1/ step 1 must approve the request, and then some approvers on stage 2/ path 1/ step 1 must approve the request, before the status of the request is Approved. Note: The approvers on stage 2/ path 1/ step 1 cannot approve the request before the approvers on stage 1/ path 1/ step 1 approve the request.
TLGroupMultiStageALL	Two sequential stages, each with one path and one step`.	TLUserList1 (assigned at stage 1/ path 1/ step 1) and TLUserList2 (assigned at stage 2/ path 1/ step 1)	All approvers on stage 1/ path 1/ step 1 and all approvers on stage 2/ path 1/ step 1 must approve the request, before the status of the request is Approved. Note: All of the approvers on stage 1/ path 1/ step 1 must approve the request before any of the approvers on stage 2/ path 1/ step 1 can approve the request.

See Application Fundamentals: Understanding Approvals.

Configuring Approval Transactions

PeopleSoft delivers the following events and email notification templates for configuring approval transactions for time and Labor:

Event	Template Name	Description
On Final Approval	HC_TL_EE_REP_APPROVED HC_TL_EE_PAY_APPROVED HC_TL_EE_OT_APPROVED	Reported time is approved, requestor notified. Payable time is approved, requestor notified. Overtime request is approved, requestor notified.
On Final Denial	HC_TL_EE_REP_DENIED HC_TL_EE_PAY_DENIED HC_TL_EE_OT_DENIED	Reported time is denied, requestor notified. Payable time is denied, requestor notified. Overtime request is denied, requestor notified.
Push Back	HC_TL_MGR_REP_PUSH_BACK HC_TL_MGR_PAY_PUSH_BACK HC_TL_MGR_OT_PUSH_BACK	Reported time is pushed back, approver notified. Payable time is pushed back, approver notified. Overtime request is pushed back, requestor notified.
Route for Approval	HC_TL_MGR_REP_AWAITING HC_TL_MGR_PAY_AWAITING HC_TL_MGR_OT_AWAITING	Reported time is awaiting approval, approver notified. Payable time is awaiting approval, approver notified. Overtime request is awaiting approval, approver notified.
Route for Review	HC_TL_MGR_REP_REVIEW HC_TL_MGR_PAY_REVIEW HC_TL_MGR_OT_REVIEW	Reported time is awaiting review, approver notified. Payable time is awaiting review, approver notified. Overtime request is awaiting review, approver notified.
On Error	HC_TL_ADMIN_ERROR	An error occurred while processing this request, admin is notified.

Note:

It is noted that the approval process will look at the Position manager as long as Employee job data is associated with a Position number and approvals will be routed to Department manager when there is no Position number mentioned on Job data page. So if the employee does not have Reports To position number mentioned on Job data page, then the system will look at Position data to find the Report To.

See

Note:

These templates are delivered. If modifications are needed refer to the Applications Fundamentals Documentation. The events delivered must not be modified to ensure the correct functioning of the Time and Labor Self Service applications. You might be able to modify this set up if you have a thorough understanding of the Approval Framework, PeopleCode and Time and Labor Self-service.