Working with TableSets

Tableset Sharing

Tableset sharing enables you to share some or all of your control table data from business unit to business unit, instead of having to enter the same data multiple times. The key to sharing that information is determining which rows of data can be shared across business units, which should be shared across some business units but not others, and which should be restricted.

For example, you can centralize redundant information such as country codes in a set ID that is shared while keeping information such as departments and job codes decentralized amongst different set IDs. The goal of tableset sharing is to minimize data redundancy, maintain data consistency, and reduce system maintenance tasks.

Tablesets form the building blocks of your HCM system. You populate the individual tables in the tableset according to your particular business rules or processing options. You can also mix and match tablesets by updating tableset assignments for a business unit using the TableSet Control component (SETID_TABLE).

You aren't required to share all tables in a tableset. With PeopleSoft HCM, you can share any combination of tables with any number of business units, according to your needs. Use the TableSet Control page to identify which data should be shared and how it should be shared for each business unit.

This diagram shows how one tableset is shared across all three business units in an organization for one group of records, the job code records, and for another group of records, the location records, each business unit uses it's own set ID. For the third group of records, salary plans, one table set is shared between two business units, ABC and QRS, but the third business unit, XYZ, uses the values created under another set ID:

Record Groups and Tableset Sharing

For the purpose of tableset sharing, control tables are divided into record groups. A record group is a set of control tables and views that use the same group of set IDs in the same manner.

Record groups serve two purposes:

• They save time by enabling you to set up tableset sharing without an enormous amount of redundant data entry.

• They act as a safety net by ensuring that tableset sharing is applied consistently across all related tables and views in your system.

A record group can contain a single table or many tables and views. You can update or modify which tables and views are included in each record group by using the Record Group component.

Business Units and set IDs

When you create a business unit, you must assign to it a default set ID. You have two options:

• If you want to create rows of data in the control tables that should be used only by this new business unit, create a set ID for the business unit when you create the business unit.

  You can create a set ID at the time you create a business unit by accepting the business unit code in the Set ID field. When you do this, the system creates a record set ID on the TableSet IDs component when you save the business unit.

  Note: This is the best option if you are only using one business unit.

• If you want the business unit to share rows of table data (tableset sharing) with other business units, select the existing set ID that is or will be associated with the data rows you want to make available to this business unit.

Regardless of which option you choose, when you save the business unit the system creates an entry in the Tableset Control component for that business unit and associates with each record group the default set ID you selected for the business unit. You can change the set ID assignment in the TableSet Control component.

This diagram shows the relationship between set IDs and business units and illustrates the information the system creates for the business unit in the TableSet Control component where you can change some or all of the set ID assignments:

Scenario 1: A Control Table with Multiple Set IDs, but No Defaults Based on Those Set IDs

An example of a control table that is associated with multiple set IDs is the Departments component (DEPARTMENT_TBL). The record for the component, DEPT_TBL, has two set IDs: the set ID for the department and the set ID for the department's location. The set ID for the location prompt comes from the LOCATION_TBL record.

This example illustrates the Department Profile page.

In this situation where this is a department set ID and a location set ID, you can set up the component so that the system makes available in the Location field:

• All locations from all set IDs.

• Locations that share the same set ID and the department's set ID.

Making all locations available may cause problems if a user creates a department with a location in a set ID that is not used by any business unit with access to the department's set ID. Making only one location set ID available could cause problems if business units with access to the department's set ID use different location set IDs.

For example, an organization has the following tableset controls set up for its four business units for the DEPT and LOCATION record groups:

If you limited the location set ID to the set ID of the department, you would not be able to set up departments with a valid location for the ASIA and RUSS business units. If you made all locations in all set IDs available, you run the risk of users creating a department in set ID USA with a location in set ID EURO.

To limit the locations available to a department, while still accommodating the different tablesharing arrangements, you could limit the location set IDs to USA and ASIA when the department set ID is USA and to RUSS and EURO when the department set ID is EURO.

Scenario 2: A Transaction Table with Multiple Set IDs Controlling Defaults Across the Transaction Record

An example of a transaction table that has multiple set IDs controlling defaults across the record is the Job Data component (JOB_DATA).

When you create a job data record for someone, you select a business unit on the Work Location page (JOB_DATA1). The system uses the business unit's tableset controls to determine which values to make available in other fields on the component and when to use established defaults.

The system only displays departments that are in the set ID selected for the business unit and defaults in the department's location only if the location is in a valid set ID for the business unit. Locations have associated salary plans, and the system defaults in the location's salary plan only if the salary plan is in a valid set ID for the business unit. If a default value is not in a valid set ID for the selected business unit, the system leaves the field blank and the user selects a value from the options in the valid set ID.

For example, in the Job Data component, select the business unit, such as PDEV as shown in this diagram. The system references the tableset controls for that business unit to determine the valid set IDs for many of the other fields on the component, such as Department, Location, and Salary Plan:

When you select the Department lookup button in the Job Data component, the system references the TableSet Control table for the record group row that determines which department set ID is available for this business unit. Since USA is the designated set ID for the department record, the system only displays in the search list those departments with the USA set ID. In the diagram below this would be departments USA-00001 and USA-00002:

The system also checks to see if the set ID of the location associated with the department is valid for this business unit.

In this example, only locations with the set ID USA should be valid for the PDEV business unit. When the location associated with the department uses the set ID USA, such as department USA-00001, which is associated with location USA-NY, the system enters the default location in the Location field. If you were to select department USA-00002, the location associated with this department, with the set ID ASIA, will not default into the Location field. The system leaves the Location field blank:

If the salary plan is associated with the location, the system checks the TableSet Control record for the business unit, in this example PDEV, to see if the set ID of the salary plan associated with this location is valid for this business unit. Since valid values for this business unit should be associated with the USA set ID, and the salary plan associated with the USA-NY location uses a salary plan set ID of SHARE, the salary plan will not be provided by default into the worker's record:

When you select a salary plan, the system will only retrieve those rows from the Salary Plan table that begin with set ID USA, as defined on the tableset controls for business unit PDEV: