Effective California Meal Penalty management using Time Clocks in PeopleSoft

Wage and Hour legal requirements in Calfornia necessitates that all non-exempt employees should get 30 minutes of uninterrupted meal break after working for 5 hours. If there is a violation of this law, employers are supposed to pay a penalty to the employee. It is a common requirement to encode this rule into PeopleSoft Time and Labor for CA based implementations. We have seen instances where employees get around this rule by cleverly clocking in 2 or 3 minutes prior to the 30 minute meal break period (that is, taking a meal break for 27 or 28 minutes instead of 30) and thus getting entitled for the meal penalty payment. For companies with a significant non-exempt population, this can amount to hundreds of thousands of dollars in payroll leakage. An effective way in which we have reduced the abuse of this rule is to take advantage of the capabilities at the time clock level. In PeopleSoft Time and Labor implementations with an integration to a Time Clock (or a Time Collection Device in PeopleSoft parlance), we have got the time clock vendor to put a restriction at the clock side to prevent employees from clocking In from their meal breaks prior to 30 minutes. This means that if an employee tries to clock in after 28 minutes of meal break, the clock will issue an error message to the effect that 'You have not completed your 30 minutes of stipulated meal break' and prevent the employee from clocking in. If there are scenarios where it is required by business urgency for the employee to clock in, we can designate a supervisor who can override this restriction.
When you are designing your Time and Labor system, make sure that all potential areas of Payroll leakage is being addressed and an integrated system solution can surely help prevent these costly leakages!

This post is authored by HRoi Consulting - The PeopleSoft Time and Attendance experts

KABA BCOMM integration with PeopleSoft Absence Management

KABA is one of the two certified time clock vendors for Oracle PeopleSoft Time and Labor. There is a bi-directional integration between KABA and T&L, with T&L sending the TCD (Time Collection Device) and time reporter data to KABA and KABA sending the punch/elapsed time data to T&L. The integration of KABA and Time and Labor is pretty seamless and my experiences with the product has been very satisfactory. In a recent product demonstration by KABA, I got to know that they are developing an interface with PeopleSoft Absence Management, which will allow users to book absences directly on the clock. According to the KABA account manager who was giving the product overview, the integration with Absence Management should be generally available by Q2 of 2011. This is an interesting development as it will ease absence reporting for employees in operational industries (like manufacturing/retail/hospitality etc.), integrate time and absence reporting to a single application, authenticate employees based on a badge/biometric data (thereby eliminating the need for employees to remember the username and password for various applications) and possibly eliminate the need for employees to spend time in a computer kiosk (with associated authentication, caching and security concerns). But, absence reporting is completely different from time reporting and it will be interesting to see how the product from KABA is positioned to deal with all the challenges. Nevertheless, it is a feature which customers would want to evaluate while deploying PeopleSoft Time and Labor and TCDs.

Simulating Time Collection Devices using Peoplesoft Handler Tester Utility

What would you do if you had to send adhoc punches from a TCD to Peoplesoft for testing and you don't have access to a TCD or an immediate mechanism to send offline punches? Use the Peoplesoft Delivered Handler Tester utility. Handler Tester is a tool where you can feed the XML file and simulate the invocation of the handler of a Service Operation. It is an excellent utility while you are developing any service operation.
Any punch time interface that comes from a TCD calls the PUNCHED_TIME_ADD Service Operation. Extract the XML of the message (this can be easily taken from the Service Operation monitor) and make appropriate changes to the XML file (like adding the correct EMPLID, PUNCH_DTTM, PUNCH_TYPE etc.) and submit the XML to the tester using the 'Provide XML' button. To fire the handler - click on 'Execute Event'. If the handler was fired a text - 'Done' will be displayed below the Execute Event button. Check the Process Monitor to see whether there is an instance of the ST_LOADER AE. The handler calls the ST_LOADER AE that actually loads the punch time to the TL_RPTD_TIME table. I found it to be a very handy mechanism to simulate the action of TCDs.
A snapshot of the Handler Tester page is given below: