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.