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.

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.