Time Clock vendors for PeopleSoft Time and Labor

Integration with an external time collection device or a time clock is an integral piece to a Time and Labor solution. Time clocks can be used to collect the work punch time of employees, collect task level information, enforce schedule restrictions etc. PeopleSoft Time and Labor provides a bi-directional integration with third party time clocks that allows T&L to send and receive data from time clocks. The interfaces related to time clocks are XML based and utilises PeopleSoft's integration broker technology. This facilitates an open framework where other third party time clocks can consume the time clock related messages from PeopleSoft and send punch data to PeopleSoft in the desired XML format.
It is to be noted here that Oracle has verified integration with some time clock vendors. The advantage of partnering with the time clock vendors with an Oracle verified integration is that there will be a ready made interface supported by both Oracle and the time clock vendor. The time clock vendor will further support any changes that result from upgrades as well. Thus, there are significant advantages for customers to choose time clock vendors that have an Oracle Verified Integration to PeopleSoft Time and Labor.
The vendors with Oracle verified integration are:

1. Accu Time Cesium
2. KABA
3. Timelink

We strongly recommend customers evaluating the implementation of a time clock in a PeopleSoft HCM context, to consider partnering with one of the above three time clock vendors.

Disclosure: Accu Time is a past client of HRoi Consulting, but this post is neither sponsored nor endorsed by Accu Time.

Oracle acquires cloud social marketing firm - Virtue

Oracle has announced that it has entered into an agreement to acquire Virtue - a leading cloud based social marketing company. According to Virtue's website -
"Vitrue partners with brands, marketers and agencies around the world to help them maximize their social community engagement through the powerful Vitrue Social Relationship Management (SRM) platform. The Vitrue SRM platform gives brands the ability to scale across multiple social networks, target global to local and publish content that engages fans and drives leads. In addition, Vitrue provides clients access to deep analytics, industry insights and best practices, product training options and high-touch customer service, giving brands a competitive advantage."

You can read the official statement from Oracle in the link below:
http://www.oracle.com/us/corporate/acquisitions/vitrue/faq-1638521.pdf

Onboarding and Exit Processes: A glaring gap in PeopleSoft HCM

Onboarding and Exit processes in an organisation are typically resource intensive, requires coordination between multiple departments, are workflow and checklist based and extremely critical for a positive employee experience. It goes without saying that there is great benefit in automating both onboarding and exit processes and integrating it with the core HCM ERP application. In this regard, it has been extremely surprising for me that PeopleSoft HCM does not deliver a framework that can be used for onboarding employees and managing the exit processes. It pains to see customers resorting to manual onboarding processes even after investing millions in implementing PeopleSoft HCM or building a custom onboarding/exit framework. SMARTERP is one company that has tried to address this deficiency in the PeopleSoft market by developing a bolt-on onboarding framework. You can find details of the product here.

This brings me to Workday. In the latest release of Workday (Workday 16), they have delivered an out of the box onboarding framework. You can read up more on this on Amy Wilson's blog here. All customers of workday can use the new onboarding framework which looks pretty cool from few of the screenshots I have seen. My thumps up to the Workday product development team for addressing a business process that benefits greatly from automation.

The real game changer with SaaS vendors in my mind is the pace at which they 'push out' significant features to customers at no extra cost. Oracle trumpeted the 'Feature Pack' concept few years back as a similar concept - more frequent releases with major functionality improvements. Unfortunately, the definition of both 'frequent' and 'major functionality improvements' differ between a SaaS vendor like Workday and an on-premise vendor like Oracle. The feature packs are released once in a year (compared to 3 to 4 major releases in a year for Workday) and I have not seen any significant functionality changes in any of the feature packs that have been released till now for PeopleSoft HCM. But, this is a topic for another blog post!

Coming back to our original discussion - I sincerely hope that Oracle PeopleSoft HCM Product managers take note of this impending market need for an onboarding and exit framework and introduce this at the latest release possible (That would possibly be 9.3 or some feature packs of 9.2 after it's released in 2013). 

When EMPLIDs differ!

Sofie was working on building an interface from PeopleSoft HCM to a third party payroll system. The payroll system was in place for the last 8 years and was following a unique employee id generation rule. Sofie's analysis showed that the employee ids in the payroll system were completely different from that in PeopleSoft and the payroll analyst told her that they required the payroll employee id in the interface file from PeopleSoft. This meant that Sofie had to map the PeopleSoft employee id to the payroll employee id in a table. The client's HRIS team ruled out the usage of Alternate Employee id for this purpose as they were already using this field for other functionalities. Sofie decided to discuss this issue with her functional lead, Mary. Mary had just completed a payroll interface project and Sofie was sure that she would get a solution from Mary. Mary suggested Sofie to use the Payroll Interface Employee Id table (PI_EMPLID_TBL) for this. The PI Employee Id table is a delivered mechanism by PeopleSoft to map the PeopleSoft employee id to the employee id in a third party system. Mary told Sofie that this table is exposed as a page online and can be found by navigating to Setup HRMS > Product Related > Payroll Interface > Interface Controls > Employee Table > Interface Employee Table. After discussions with Mary, Sofie decided to use the PI Emplid table for mapping the PeopleSoft employee id to the Payroll vendor's employee id. The overall solution for using this feature was more than just referencing this table in the payroll interface program. Sofie had to:

• Load the table with the employee id mapping of existing employees.
• Provide security to the client's HRIS team to maintain the mapping for new hires.
• Provide an Excel to CI utility for the HRIS team to load the PI Emplid table for a batch of employees.
• Provide a PS Query for the Business and HRIS teams to view the existing employee id mapping.

Process data flow of Time and Labor/Absence Management integration with Global Payroll

 A one slider on the data flow in the integration of PeopleSoft Time and Labor and Absence Management to Global Payroll. The slide also includes details on the main tables involved in the process.
For a copy of the file, email us at partner@hroiconsulting.com

PeopleSoft Time and Labor/Absence Management data flow to Global Payroll

View more presentations from jijucvengal

Business Unit, Setid, Set Control Values in PeopleSoft HCM - A Primer

The purpose of this post is to look at the concepts of Setid, Business Unit, Record Groups and Tableset Control from a pure implementation and design point of view and try to draw the relationship between these terms and their significance in a PeopleSoft HCM implementation. There is also an exercise at the end of this post for those readers who want to apply the concepts detailed in this post - so stick on till the very end!

I believe that it's easier to understand the underlying concepts of an application if you take a top down approach. That is, you start with the way the concept works in action, understand it's behaviour in an application and then dig down to unravel the underlying concepts. (Unfortunately, this is where most product documentation including peoplebooks fail. Most of them take a bottom up approach where they start detailing the concept first which leaves elementary readers with no context to understand the concept). So let's dive straight into seeing where Setid and Business Unit are used in PeopleSoft HCM transactions and understand their behaviour and then try to explain the concepts working behind the 'screens' that lead to the observed behaviour. 

Scenario Walkthrough:

Assume that you want to record the transfer of an employee from New York to Dallas in PeopleSoft HCM. To carry this out, you will navigate to the Job Data component, enter the effective date of transfer, select the appropriate action and action reason and select the location code corresponding to Dallas. When you look up the prompt on the location field in Job data, you will see that the field called 'Setid' is read-only and pre-filled with a certain value, let's say 'USA'. This is the first observation I want you to understand and question. How is the setid field of the Location prompt in Job data pre-filled with a certain value?

You select the appropriate location from the prompt and save the componen.

After you completed this transaction, you realise that you also had to change the department of the employee along with the change in location. So you navigate back to Job data and try to change the department in the effective dated row that you created for the change in location transaction. When you look up the department prompt in Job data, you again observe that the setid field in the prompt is read only and has a pre-filled value of 'SHARE'. This is the second observation that I need you to question. Why is the pre-filled value of setid different for department (SHARE) and location (USA)?

Let us try to answer these questions first.

How is the setid value of certain fields like location, department, jobcode etc. defaulted in Job data?

A number of setup components in PeopleSoft HCM like Department, Location, Jobcode, Salary Administration Plan, Employee Class etc. are keyed by the field called Setid. The significance of Setid is that it helps to drive the security behind the display of key setup values in the application. Let us assume that you are implementing PeopleSoft Workforce Administration for Australia and New Zealand. The customer requirement is that when they are hiring an employee in Australia, they should be able to look up all departments defined in the organisation, but at the same time, they should be able to select only locations that are specific to Australia. As Department and Location setups are keyed by Setid, this key can be effectively used to drive this requirement. So taking this simplistic example forward, you would have to create three setids in this case. One setid that is 'SHARED' between Australia and New Zealand, another setid that is specific to Australia and the third setid specific to New Zealand. For this customer, the setid assigned to all departments should be the shared setid, while the setid assigned to Australian locations should be the Australian setid and the New Zealand locations should have the New Zealand setid. With the setid allocation while setting up key tables clarified, let us understand how the defaulting of setids happen in Job data.

The value of Business Unit selected in the Job data component, controls the setid that will be defaulted in the Department, Location, Jobcode and Salary Administration plan fields in the Job data component. Coming back to our example of the company with operations in Australia and New Zealand, let us assume that there are two business units that have been defined - one for Australia and another for New Zealand. Prior to selecting the values for Department or Location, you will have to select the value for Business Unit in Job data (a good corollary experiment is to try to look up the department and location prompts in job data without entering any value for Business Unit. You will see that no values will be returned for Departments or Locations in this case). Once a business unit is selected, the defaulted setid values for Deparment, Location, Jobcode and Salary Administration plan is controlled by the value of the business unit field. This goes on to say that if you selected business unit of Australia in Job data, the setid defaulted for department prompt will be the shared setid while the setid defaulted for location prompt will be the Australian setid. Similarly. if you selected a New Zealand business unit in Job data, the setid defaulted for department prompt will be the shared setid, while the setid defaulted for locations will be the New Zealand setid. 

This brings us to the obvious conclusion that there should be a link or mapping between the value of business unit and setids for the various setup values. This means that there should be a mechanism where we can define that for Australia business unit, departments should have the shared setid and locations should have the Australian setid, while for New Zealand business unit, the setid for locations should be New Zealand setid. 

This mapping is achieved by the concepts of 'Table Set Control' and 'Record Groups'.

A Record Group is a group of functionally similar records. From an application point of view, there are different record groups for Departments, Job Codes, Locations etc. 

Tableset Control is the mechanism through which you can map the actual values of a business unit to the default setid for each record group. Thus, using the tableset control setup page under 

Peopletools > Utilities > Administration > Tableset Control you can define the setid that should default for each setup value for a selected business unit. Note that each setup value like Department, Location etc. will be a separate record group. So taking our previous example, to define the setid defaults for the Australian business unit, you would have to navigate to the Tableset Control page and enter the value of the Australian business unit in the search field called Set Control value. This will take you to the transaction page, where all available record groups and the corresponding setid that will be defaulted will be listed. In this page, you will have to change the setid corresponding to the location record group to the Australian setid and set the shared setid as the setid for the Department record group.  So tableset control is the link that maps the business unit values to the appropriate setid for each record group. In conclusion, this entire setup (and terms!) is only to enable organisations define how setup data should be shared/controlled between different entities in the company. 

To retrace the entire concept, let us try to run through how a setid is defaulted for a field like Department in Job data. When a user looks up the prompt of the department table in Job data, the system looks at the Business Unit entered in the component. Then the system checks the table set control setup to retrieve the setid corresponding to the department record group for the set control value of the business unit entered in the component. This setid is used as the default setid for the department prompt in Job data. 

I will leave you with one final clarification that the set control value in a tableset control definition is not necessarily always business unit. We took the example of business unit as that was relevant for our exercise. By definition, a set control value is a higher key on which the setid of a certain record group is dependent. To take an example, the set control value corresponding to the Employee Class field in Job data component (in the Job Information page) is Regulatory Region. This means that the setid defaulted in the prompt of Employee Class will be controlled by the setid attached to the employee class record group in the tableset control page for the Regulatory Region value entered in Job data component.

Exercise:
For those who want to go through some practical exercises, we are detailing a design scenario which can be tried out for practice:

Grocery One is a retail chain with operations in Singapore, Malaysia, Thailand and South Korea. They run multiple formats like Hypermarkets, Express Stores and Premium stores. The organisational structure of Grocey One treats each physical store as a department and the departments are organised based on the format and country. This means that all individual Express Stores in Singapore roll up to a master department that administers Express Stores in Singapore. These master departments per format and country further roll up to the country head department of each country and the country head departments of each country finally roll up to the CEOs office. HR Administrators of Grocey One would like to make sure that the departments and locations that are shown in Job data is restricted to the format and country, while all job codes for a certain country should be displayed irrespective of the format.

1. How should the business units be designed for Grocery One in PeopleSoft? How many business units would you suggest to have for Grocey One in PeopleSoft?
2. What is the minimum number of setids that will need to be created?
3. How can the restriction of department, location and job code values in Job data be achieved as per the requirements of Grocey One HR Administrators?
4. What is the impact of your design on inter-store and inter-country transfers?
5. Will your design allow Grocey One to easily report the head count based on format and country, at the country level and at the total organisation level?

Have fun with the exercise! We would love to hear your design approach, write in at partner@hroiconsulting.com if you want to have a word!

This post is authored by HRoi Consulting - The PeopleSoft Time and Attendance experts. HRoi Consulting specialises in the implementation and optimisation of PeopleSoft WFA, Time and Attendance and Payroll modules.

Configurable Matrices as Mapping Tables

There was a discussion in ITToolbox on using Configurable Matrices to act as mapping tables. This is one utility we have used successfully for maintaining mapping values in PeopleSoft without the need to develop custom records, components or pages.

So, what are Configurable Matrices?
Configurable Matrix is a delivered functionality in PeopleSoft to maintain a matrix of input values and their corresponding results. This is very similar to the concept of Brackets in Global Payroll and Absence Management. You can easily define a Configurable Matrix by defining the input fields, the result fields and the data correlation between the input and result fields.

Can you give an example where Configurable Matrices can be used?
Here are some examples where we have used configurable matrices as mapping tables:

1. In a multi-country implementation, one customer wanted to control the open period of Timesheet based on the country and role. For example - in Country A, the timesheet had to be open for only the current period for employees and current and past period for managers. While, in Country B the timesheet had to be open for the current and past period for employees and managers.
Rather than hard-coding this logic in peoplecode or creating a custom table, we simply created a Configurable Matrix definition with country and role as the input fields and the open periods as the result field. In the peoplecode customisation to control the timesheet open periods, we queried the Configurable Matrix data to get the appropriate open period based on the country and role of the user.

2. One customer wanted to maintain default work schedules per company. We suggested the use of Configurable Matrices to maintain this relationship.

What are the advantages of using Configurable Matrices?
Configurable Matrices are an out of the box solution. This means that the use of CM will help implement a vanilla solution and eliminate the need to create custom records, pages and components. Coupled with this, we have found that the development time can also be significantly reduced by using this option.

Would you suggest using Configurable Matrices for all mapping requirements in PeopleSoft?
No. We recommend using Configurable Matrices to maintain mapping values that remain mostly static. For example, in the ITToolbox example we quoted earlier, the requirement was to maintain the mapping between a Department and the HR Representative of the department. This is something that requires to be tightly coupled to the Department component, needs constant maintenance and has to be effective dated. For such requirements with dependency on effective dates and those that require constant updates are best maintained as custom objects. But, for mapping tables that do not change frequently, the cost of creating custom objects far outweigh the benefit achieved and we strongly recommend the use of Configurable Matrices.

I want to try this out. Where can I find Configurable Matrices setup in PeopleSoft HCM?
Here you go - Setup HRMS > Common Definitions > Configurable Matrices.
Have fun!

Peopletools 8.52 and iPad Certification! Finally!!

Finally we are seeing some action from Oracle with respect to PeopleSoft HCM and mobile devices.

Time and Labor enrollment through Template Based Hire

Enrollment of employees into Time and Labor is a pre-requisite in every PeopleSoft Time and Labor implementation. Most implementations have a custom enrollment process to automate the assignment of Time and Labor attributes to employees. We want to present the option of using Template Based Hires (Smart Hire) to drive the initial Time and Labor enrollment of employees. Template Based Hire is a powerful functionality in PeopleSoft Workforce Administration module, that can be used to fasten the data entry related to hiring an employee in PeopleSoft. Using Template Based Hire, we can create custom templates containing only the fields that are relevant to a company/position. Defaulting of values can also be done for the fields and this helps in reducing the data entry requirements. A Template Based Hire template is made up of multiple sections. Each section contains a list of fields pertaining to a certain functional area. There are delivered Template Sections related to Time and Labor enrollment functionality, that can be added to a Template Based Hire template. If employees using a certain Template have common Time and Labor attributes, the values of the T&L attributes can also be defaulted through the Template Based Hire setup.

This solution of using Template Based Hire templates for Time and Labor enrollment can be applied to implementations where the Time and Labor enrollment details of employees do not change frequently. In such cases, customers might have a lower Total Cost of Ownership using Template Based Hire templates rather than developing a custom process to automate the entire enrollment. 

a screenshot of a Template section related to Time and Labor is given below:

Template Section related to Time and Labor added in a TBH Template

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

Design Flaw in PeopleSoft Work Schedule Defaults and design in Oracle Fusion HCM

For a Human Resources ERP suite, PeopleSoft HCM has excellent Time and Attendance features. One area that is highly under-appreciated (but lauded by customers when they see the complete potential!) is the Schedule Management features in PeopleSoft Time and Labor and Absence Management. Some of the features, like the ability to define flexible work schedules, ability to create work schedules on the fly, integrated Time Calendar views with Time, Absence and Training information etc. are very exciting and useful. In this post, I want to highlight a glaring flaw in the design of the work schedule defaulting feature in PeopleSoft. A Work Schedule can be attached at multiple levels in PeopleSoft HCM, for eg:
a. At the employee level in the Assign Work Schedule page (underlying datastructure is SCH_ASSIGN)
b. At the Absence Management/Global Payroll Paygroup level
c. At the Payroll for North America Paygroup level
d. At the Time and Labor workgroup level

If a work schedule is not directly attached to an employee, PeopleSoft follows a specific hierarchy to resolve the work schedule that has to be assigned. In this hierarchy, Absence Management/Global Payroll paygroup takes precedence over Payroll for North America paygroup, which takes precedence over Time and Labor workgroup.
In our opinion, it is not a good practice to default a work schedule from a Paygroup or Workgroup. The primary purpose of a Paygroup/Workgroup is to group employees with similar pay/absence/time characteristics together and is not to group employees working similar schedules. The fact that Absence Management/Global Payroll paygroups take precedence over other definitions makes the case more rigid in our opinion. This is because, the Global Payroll/Absence Management organisational and processing frameworks are extremely flexible. It is possible to define very generic paygroups and then drive application of specific rules to concerned group of employees through the use of conditional processing elements or even payee level overrides. An optimal design of Absence Management/Global Payroll frameworks should make use of this inherent product flexibility and design simple,lean and flat frameworks. The simpler the configuration, the more generic will be the assignment of paygroups, i.e. most employees will share the same paygroup. But, most often it is required to have more specific groupings for the purpose of work schedule defaults. So a simplistic Absence Management/Global Payroll framework design will not help in proper defaulting of work schedules. We have seen many legacy Time and Attendance applications (applications from which the client moved to PeopleSoft Time and Attendance) where the time processing rules were tightly tied to the work schedule of employees. This is our mind is similar to the concept of tying a work schedule to a paygroup/workgroup. But, all these systems suffered from the complexity introduced by the tight coupling of rule processing groups and schedules and the same deficiency exists in PeopleSoft as well.
My suggestion to the PeopleSoft Time and Labor/Absence Management product managers would be to take a relook at the schedule default options in PeopleSoft and provide a mechanism to default work schedules from a data definition that is more attuned with the actual business process of wok schedule assignments. In our opinion, Jobcodes and especially Positions are excellent candidates for this. From an operational point of view, employees in a certain jobcode or position have more probability of sharing a work schedule that those in the same paygroup (ofcourse the challenge of global implementations and shared jobcodes/positions do come in here, but we believe that these definitions are better candidates for work schedule defaults than a paygroup).

In this context, we want to introduce the work schedule defaulting features available in Oracle Fusion HCM. In Fusion HCM, the hierarchy of work schedule resolution is given below:

1. Primary assignment of the worker
2. Position
3. Job
4. Department
5. Location
6. Legal Employer
7. Enterprise

It's excellent to see that Oracle Fusion HCM offers a more flexible and elaborate work schedule assignment mechanism, which in our opinion is more in tune with the business requirements. We do hope that the PeopleSoft design team takes a cue from the Oracle Fusion HCM design and provides a more flexible work schedule defaulting design.

To GP or not to GP, that is the question!

One of the most prevalent configurations in a combined Time and Labor/Absence Management implementation is to have payroll processed by a third party vendor. So, in this configuration Time and Labor and Absence Management will be processed in PeopleSoft, while payroll will be handled by a third party payroll system. For the sake of argument, let's assume that the Workforce Administration related data is passed to the payroll vendor using a custom process. The question we are discussing in this post is, what should be the Pay System chosen for assignment in Job data for employees in such a configuration? Should we assign Payroll Interface as the Pay System or should it be Global Payroll?
Common wisdom might suggest to use Payroll Interface, as the customer is not implementing PeopleSoft Global Payroll per se. But, our recommendation is to use 'Global Payroll' as the Pay System in Job data for employees. The reason behind this is many folds:
1. It eliminates the need for extra configurations to get Payroll Interface up and running.
2. Assignment of paygroup at Job data level becomes much easier as extra fields related to Payroll Interface paygroup need not be populated.
3. Integration between Absence Management and Time and Labor is possible only with pay systems of Global Payroll and Payroll for North America. Probably this is one of the most compelling reasons to choose Global Payroll as the pay system in such a configuration.

So, we strongly recommend implementations to use Global Payroll as the pay system of employees in Job data in configurations with T&L and Absence Management implemented in PeopleSoft and payroll housed outside PeopleSoft and not utilising the PI engine to send workforce administration/benefits data to the payroll vendor.

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

Fifty is the new thirty: Implications to Time and Attendance policies and systems

Seth's Godin's blog today touches upon a very topical subject - that of the challenges of an ageing population. The content of his post is pasted below:
"Baby boomers continue to redefine our culture, because there's just so many of us, we're used to being the center of attention.

Add into that the fact that we're living much longer and careers are becoming more flexible and it's pretty clear that in just about every cultural respect, fifty year olds are living, acting and looking more like thirty year olds every day.
This changes more than personal financial planning. It changes the marketing of every service and product aimed at consumers--and yet most traditional advertisers are stuck in the mindset that thirty is the end of your chance to find a new customer or build a new brand."

Much has been said and written about managing a multi-generational workforce, increasing the age of retirement, integrating older workers to the workforce etc. These factors have become a necessity for many countries to remain productive and there is no doubt in our minds that we will see policies and legislations to encourage and integrate older workers to the workforce.
This change will ofcourse call forth features in Time and Attendance product design that supports a multi-generational workforce. Time and Attendance products have been providing slick, mobile based applications in line with the current trend. But, probably the product design requirements for an older workforce is way different from that of the younger generation and it would be interesting to see how Time and Attendance product companies react to this change in employee demographics!
A more compelling challenge would be for the HR departments to design Time and Attendance policies that will support the integration of an older workforce into the organisation.
In our assessment, this impending change will translate into a unique market opportunity for Time and Attendance product/consulting companies. We foresee a niche market for T&A products that offer features supporting older workers in the workforce.

Oracle verified integration by Cesium - Time Clocks for PeopleSoft Time and Labor