Working with System Data Regulation in HRMS

This chapter provides an overview of PeopleSoft HRMS system data regulation, lists prerequisites, and discusses how to:

• Work with business units.

• Work with tablesets.

• Work with permissions lists and system defaults.

Understanding PeopleSoft HRMS System Data Regulation

As companies grow larger and more complex, they often need to collect the same type of data across many locations. PeopleSoft business units and setIDs enable you to organize businesses into logical units other than companies and departments and to define how organizational data is shared among these units.

PeopleSoft HRMS system data is regulated through the use of business units, tablesets and setIDs, and tableset sharing. Business units are logical devices that enable you to implement PeopleSoft HRMS based on how your business is organized. Tablesets, setIDs, and tableset sharing are organizational devices that enable you to share – or restrict – the information stored in your HRMS system across business units:

Components Used to Set Up Business Units and SetIDs

Once you've developed your business unit map, use the following components to set up business units and setIDs and to define system defaults based on permission lists or business units:

Prerequisites

Before you implement PeopleSoft HRMS, take a close look at how your business operates and analyze how you want to map your organization's business structures, practices, and procedures.

You can set up business units and tableset IDs before or after setting up the Installation Table component (INSTALLATION_TBL) and entering companies on the Company component (COMPANY_TABLE). However, you should set up the Installation Table component and Company component before continuing on to the TableSet Control component, Business Unit Options Defaults component, and Org Defaults by Permission Lst component.

Working with Business Units

This section provides an overview of business units and discusses how to determine your business unit structure.

Understanding Business Units

Business units are logical units that you create to track and report specific business information. Business units have no predetermined restrictions or requirements; they are a flexible structuring device that enable you to implement PeopleSoft HRMS based on how your business is organized.

Business units share processing rules and you can create them at any level of the organization that makes sense and that reflect the needs of your internal human resources departments. If you use the same processing rules across the organization, it may make sense to have a single business unit; if you use different rules in different companies, countries, or functional areas, you may choose to create multiple business units.

Because PeopleSoft HRMS doesn't offer any predetermined definition for a business unit (as it does for a department and a company), you can implement this organizational level in your PeopleSoft HRMS applications to reflect your own enterprise's structure. You can share business units across any combination of PeopleSoft Enterprise HRMS, Financials, Manufacturing, and Distribution applications or define them in just one PeopleSoft Enterprise application.

Note. For PeopleSoft HRMS, you must establish at least one business unit.

You have complete control over how you define business units in your PeopleSoft HRMS system, as well as how you use them to facilitate the handling of data in your data organization. For example, you could set up a business unit for each legal entity in your organization, all to be processed by a central human resources department that interfaces with and manages each business unit's information, workers, and processes. Alternatively, you could set up one business unit for each company, location, or branch office in your enterprise, enabling each unit to manage its own human resources information independently, while sharing data with a central, parent business unit.

While each business unit maintains its own human resources information, your organization can maintain a single, centralized database, reducing the effort of maintaining redundant information for each business unit. More importantly, as this diagram illustrates, you can produce reports across business units, enabling you to see the big picture and to compare the finest details.

A centralized data enables analysis and reporting across business units

See Also

Control Tables, Transaction Tables and Prompt Tables

Determining Your Business Unit Structure

Business units offer a flexible structuring device through which you can implement PeopleSoft HRMS based on the way your business is organized. In some organizations, the correspondence between existing structures and the business model is obvious. In other cases, it may take some careful thought and analysis to determine how to set up the business units to best reflect your organizational structure and to best use the exceptional power and capabilities of PeopleSoft HRMS. When deciding how to establish business units for your PeopleSoft HRMS implementation, keep the following points in mind:

• With business unit functionality, you have another level for associating a person with your company's organizational scheme.

• Business units are always associated with a job, position, and a person's job record.

• Business units have no predetermined definition (unlike department and a company). You can implement this new organizational level as you determine its usefulness to your enterprise.

• Business units are not legal entities, but a way of tracking specific business information for reporting and other rollup data collection.

Work closely with your PeopleSoft implementation partner early in your design to determine how best to define the business units for your PeopleSoft HRMS system. Every organization has different requirements, and it's not possible to cover all the variables that you might encounter. However, once you've identified your business unit structures and made a tentative decision about how many business units you'll need, take a step back and ask the following questions:

• Are the business unit structures and number of business units correct?

• Is there any reason why these structures would not work?

• Will these structures preclude me from taking advantage of some functionality that I might want to use?

• Will these structures restrict my reporting options?

• Will these structures cause me to process more than I want to process on any particular night?

Possible Business Unit Structures

How you define a business unit depends on your industry, statutory requirements, regulatory reporting demands, or how you've organized operating responsibilities. Consider the following scenarios and the supporting diagram below:

• 789 Inc. chooses to organize information by functionality or purpose, such as what is going on in Sales versus Customer Service. It has created business units that reflect the administrative needs of their human resources, benefits, and payroll departments.

• LGC Banking treats each branch as a business unit, which means that the bank could do reporting for its people within each branch.

• 123 Global Business is a multinational company that separates its operations geographically because of the necessities of conducting business abroad. What is more important to this organization may not be each office, but each location. What's happening in their American facility versus their European or Asian market? Then they can track their business requirements and business needs accordingly.

• XYZ Entertainment has subsidiary companies. A highly diversified organization like this one might choose to define each subsidiary company or cost center as a business unit. They might have a hotel business as well as a retail business and they might want to keep this information separate, yet still be able to roll everything up into one database and maintain it in a single location.

Business units can be set up to represent functional areas, branches, regions, subsidiaries, or what best fits your organization's needs

You can also use a combination of all of these methods, or any other entity or entities that makes sense for your organization. You can have as many business units as you need, although the more business units you establish, the more information you need to maintain. You do, however, need to have at least one business unit in the system.

Implementing Business Units

While you can implement one business unit for your entire organization, establishing multiple business units can offer important reporting and data control options. Multiple businesses units enable you to:

• Maintain a tree structure to facilitate organization-specific, rollup reporting.

• Distribute administration of certain control tables, such as the Department component (DEPARTMENT_TBL) or the Location component (LOCATION_TABLE) to different business units.

  For large or multinational companies, this feature of business unit functionality in PeopleSoft HRMS is useful for controlling data flow across different parts of the enterprise.

Note. If you implement PeopleSoft Enterprise Benefits Administration, you can define eligibility rules that determine workers' benefits eligibility based on their business unit affiliation.

Working with TableSets

This section provides overviews of tablesets and discusses how to:

• Set up tableset sharing.

• Control data sets.

• Reference multiple setIDs.

Understanding Tablesets

To work with tablesets, you need to be able to distinguish between tablesets, setIDs, and tableset sharing:

Note. The terms tableset and setID are sometimes used interchangeably. In many cases, this is correct, but it can cause some confusion.

You can define as many tablesets as you like, but the more you create, the more complex tableset sharing becomes. Some organizations need only one tableset.

Note. For PeopleSoft HRMS, you must create at least one tableset and setID.

Since you use setIDs to distinguish sets of rows in a table, you will always have the same number of setIDs as you have tablesets. For example, the following diagram shows four control tables. Each color within the table represents a setID, and all rows with the same color represent a tableset. Tables A and B are made up of three tablesets each, and tables C and D consist of four different tablesets, but there is a total of five setIDs, or tablesets, between the four tables:

SetIDs differentiate rows of data in a table and identical setIDs make up tablesets

PeopleSoft Enterprise Human Resources control tables that are keyed according to setID include the:

• Location component.

• Department component.

• Salary Plan component.

• Job Code component.

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 setID that is shared while keeping information such as departments and job codes decentralized amongst different setIDs. 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 HRMS 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 HRMS, 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 setID. 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 setID:

Table sets can be shared across business units or be unique to a business unit

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 setIDs 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 SetIDs

When you create a business unit, you must assign to it a default setID. 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 setID for the business unit when you create the business unit.

  You can create a setID at the time you create a business unit by accepting the business unit code in the SetID field. When you do this, the system creates a record setID 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 setID 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 setID you selected for the business unit. You can change the setID assignment in the TableSet Control component.

This diagram shows the relationship between setIDs 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 setID assignments:

Tableset controls determine which tableset a business unit uses for which record group

Setting Up TableSet Sharing

Setting up tableset sharing is easy. Use tableset controls to make data available across business units or restrict to certain business units. Before you set up tableset controls, create:

• Record groups

• Business units

• SetIDs

When you create and save a business unit, the system creates a record in the TableSet Control component for the business unit (the Set Control Value) and populates the setID for each record group with the setID you selected for the business unit. If you want the business unit to have access to the rows in other setIDs for certain record groups, change the default setID to the appropriate setID. This means that a lot of tableset sharing setup is done for you behind the scenes.

Controlling Data Sets

The system filters the field options available to the user in the transaction components based on the tableset controls you set up. For example, when a user is creating a job data record for a new worker and selects the drop down list for the Job Code field, the system filters the available options by determining the following:

1. What business unit is this person's job data record in?

   USA

2. What table controls data for this field (Job Code)?

   JOBCODE_TBL

3. What record group is that table in?

   HR_02

4. What setID is assigned to that record group for this business unit?

   SHARE

5. What rows in the control table (Job Code Table) are keyed by that setID?

   1. The system looks only for the job code with the SHARE setID values.

   2. The system makes available to the user only the rows keyed by the SHARE setID.

This diagram shows the tableset controls for the USA business unit and illustrates how the system determines which job code values to display for that business unit, as described above:

Retrieving valid control table values for a field based on business unit tableset control setIDs

If the user were accessing a field whose control table was in record group HR_01, the system would display the values keyed by the setID USA from the corresponding control table. The data the system makes available to the user depends on the setID specified in the TableSet Control component for the record group that contains the control table the user is accessing.

Referencing Multiple SetIDs

Occasionally, some pages have references to more than one setID. It's important to understand how the Page Processor works through such a situation when you're working with setID functionality. This will help you to understand how the system is making decisions about default values in the data record.

Two scenarios exist in PeopleSoft HRMS where a table that is keyed by one setID also has fields that prompt onto another setID table:

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

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

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

• All locations from all setIDs.

• Locations that share the same setID and the department's setID.

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

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

Note. Set up tableset controls on the Tableset Controls component.

If you limited the location setID to the setID 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 setIDs available, you run the risk of users creating a department in setID USA with a location in setID EURO.

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

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

An example of a transaction table that has multiple setIDs 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 setID selected for the business unit and defaults in the department's location only if the location is in a valid setID 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 setID for the business unit. If a default value is not in a valid setID for the selected business unit, the system leaves the field blank and the user selects a value from the options in the valid setID.

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 setIDs for many of the other fields on the component, such as Department, Location, and Salary Plan:

Select the business unit, which determines the valid setIDs for many fields in the component

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 setID is available for this business unit. Since USA is the designated setID for the department record, the system only displays in the search list those departments with the USA setID. In the diagram below this would be departments USA-00001 and USA-00002:

The system only displays values keyed by the designated setID identified for this field's prompt table for this business unit

The system also checks to see if the setID of the location associated with the department is valid for this business unit. In this example, only locations with the setID USA should be valid for the PDEV business unit. When the location associated with the department uses the setID 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 setID ASIA, will not default into the Location field. The system leaves the Location field blank:

The system only enters the default location value from the Department table if it is in a valid setID for the person's business unit

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 setID 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 setID, and the salary plan associated with the USA-NY location uses a salary plan setID of SHARE, the salary plan will not be provided by default into the worker's record:

The system does not enter the default value if the value's setID is not valid for the business unit

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

You can only view and select from values with the valid setID as defined for the field

Note. Many of the setID driven control tables enable you to review which business units have access to the selected setID so that, as you set up your control values, you can confirm that they will be available to the appropriate business units.

Working with Permissions Lists and System Defaults

This section discusses how to:

• Link to permissions lists.

• Define business unit HR defaults.

• Determine system default values.

Linking to Permission Lists

PeopleSoft security is based on building blocks called permission lists. Permission lists grant users access to applications, functionality, menus, data, and so on. Most permission lists are grouped into roles and the roles are granted to users. However, there are four permission lists that control specific aspects of the application that are assigned directly to the user profiles.

One of these permission lists, the primary permission list, determines which default values the system enters for the user (among other things). On the Org Defaults by Permission List component (OPR_DEF_TBL_HR) set up primary permission lists with:

• Default values for the following fields:

  • Business Unit

  • SetID

  • Company

  • Country

  • Regulatory Region

  • To Currency

  • Currency Rate Type

• Application settings, such as the payroll system and industry.

When a user logs onto the system, the system references the user's primary permission list to determine which settings to apply and which values to enter as defaults on components that support primary permission list defaulting. This helps to ensure that users are entering the right information for the kind of work that they do.

Note. Not all components use the defaults from the primary permission list.

Warning! Not associating system users with permission lists can result in serious data errors in PeopleSoft Human Resources.

See Also

Setting Up and Administering HRMS Security

Enterprise PeopleTools PeopleBook: Security Administration

Defining Business Unit HR Defaults

When users access an HCM component, the system populates some of the fields, such as business unit, company, and country using the values you associated with the user's primary permission list. You can also associate default values with setIDs on the Business Unit Options Defaults page (BUS_UNIT_OPT_HR).

Using the tableset controls and business unit default options you set up, the system determines the default values to enter in select fields on the transaction component. The system uses these defaults only on components where the system identifies the business unit field as a source for default values.

To set up business unit defaulting:

1. On the Tableset Control – Record Group page (SET_CNTRL_TABLE1), select the setID that controls business unit defaulting for this business unit.

   This enables you to share defaulting rules across business units.

2. Enter the setID's default values on the Business Unit Options Defaults component.

When a user accesses a component, which is driven by business unit defaulting, and selects a business unit, the system determines which setID drives defaulting for that business unit by referencing the record group BU Defaults on Tableset Control table. For example, for business unit PDEV, the setID for the record group BU Defaults row is SHARE. The system references the Business Unit Options Defaults component for setID SHARE to retrieve the default values and then enters those values in the transaction component, as this diagram illustrates:

The system determines the defaults for a selected business unit by referencing the tableset controls and the business unit default options

Note. The record group containing the Business Units Options Default record (BUS_UNIT_OPT_HR) is HR_06.

Setting up business unit defaults on the Business Unit Options Defaults page makes sense when you have multiple business units that share the same kind of defaults; but shared defaults are not readily organized by permission list but rather setID.

Determining System Default Values

Most of the page-level defaults in the PeopleSoft HRMS system are based on the primary permission list as opposed to business unit. Business unit defaulting generally only occurs on components that are driven by the business unit or that use EmplID as a high-level key.

This table lists the four most common scenarios in which the system must determine which default values to use, either the defaults that you defined on the Business Unit Options Defaults component or on the Org Defaults by Permission List component:

Warning! The paradigm above isn't strictly followed in the system and should be used as a guideline only. Actual defaulting at the page level is governed primarily by page functionality.

Note. Some degree of flexibility has been incorporated for exceptions to those pages that don't fall into either of these categories.

See Also

Enterprise PeopleTools PeopleBook: Security Administration

Enterprise PeopleTools PeopleBook: Data Administration Tools