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 firstname.lastname@example.org
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.
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.
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 email@example.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.
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.