I was just going through some blogs which clearly explains concepts of Setid, Business Unit, Record Groups and Tableset
Control .
I am just posting the same content here .
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.