Delivered Rapid Time Entry vs HS Time Entry

This is the continuation of our case study to build a custom Time Entry process based on delivered Rapid Time Entry. See: Introduction:Custom Time Entry

The major distinction between Delivered Rapid Time and our Time Entry (HS Time Entry) is that Rapid Time operates based on a day, rather than record-by-record. If we are in Replacement Mode and new records are added for a date, then those records replace all the records for that DUR. That is, if we are in Replacement Mode and we create a record for the DUR 12/31/2013, then Rapid Time first deletes all Reported Time records that have an RT_SOURCE of 'SYS' and a DUR of 12/31/2013. Also, Rapid Time does not load existing Reported Time records for editing. In contrast, our Time Entry loads all of the employee’s records for the week. We manage individual changed records, new records and deleted records based on the record key, not a DUR.  Also, we will operate on records regardless of the RT_SOURCE. That is, if security allows it, a record with an RT_SOURCE of 'TCD' (Time Control Device) may be removed.

Search Page

Rapid Time Entry allows time to be entered for any employee and for any date. The Search Criteria are based on new or existing Session and a User ID.

HS Time Entry requires both an Emplid and an EmplRcd. The employee's name or or Badge ID can be used, but these will map to Emplid/EmplRcd.  The week is initially defaulted to the current week, but that can be changed on the Time Entry Page.

Data Entry Page

Rapid Time

Time is entered as either Elapsed or Punch. The two types cannot be mixed on the page.  Also, time is entered in one of three Processing Modes:

Addition: Add a record to Reported Time

Replacement: Delete the set of employee records in Reported Time containing the DUR and replace them with the new set of records.

Correction: This mode is session based. Existing Reported Time with the same Session ID (ST_INSTANCE) will be overwritten by the current set of records.

HS Time Entry

Elapsed and Punched Time can be entered on the same page grid and entry is limited to a single employee. The Process Mode is always Addition. We resolve the Session ID’s and clearing of existing Reported Time behind the scenes during Save and Submit Actions. 

Case Study: PeopleSoft Custom Time Entry - Introduction

This is a case study that follows our build of a custom front-end for PeopleSoft's Rapid Time Entry Process. This project is not yet completed, but while implementing what we thought would be a simple process we have encountered some interesting problems. This blog topic follows our experience as we work through the project. It will show dead-ends, why they were dead-ends, and how we backed out and refactored the process.

The custom process will replace a custom VB/ASP .NET application. We want to retain the ability to enter time through a page for a single employee for a pay period, but eliminate the need to maintain a program outside of PeopleSoft. Delivered behavior for storing to Reported Time changed in HCM 9.1 and may change again in HCM 9.2. We want to attach to the delivered Rapid Time Process to eliminate our need to modify the VB code with each upgrade. It will also allow us to take advantage of built-in features such as scroll and buffer management, row-level security and field and record validations.

This diagram below shows the original vision. An Employee's Time is loaded from Reported Time (TL_RPTD_TIME), edited in the Time Entry Page, and then converted to either Punch or Elapsed Time formats that can be fed through the delivered Rapid Time Entry Process back to Reported Time.  

Some additional requirements:

1.     Time Entry is by Employee and Employment Record (EMPLID/EMPL_RCD)

2.     The page presents only one week at a time for editing, but the operator can move through weekly by Previous/Next Action or by entering a date that falls within the desired weekly period.

3.     Time may be added. Existing Time may be Deleted or Edited.

4.     The operator must save changed data as they move out of a weekly period, but the data will not be submitted until a Submit Actions is selected.

5.     Security will be applied:

a.      An employee can add/delete/update only in the current Pay Period

b.     Employees can only modify time entered in the Time Entry Page. They cannot modify Clock time.

c.      The employee’s Managers can modify Clock Time and Previous Period Time.

Next: Delivered Rapid Time Entry vs. HS Time Entry