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.

• Work with job records.

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 List 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, you can produce reports across business units, enabling you to see the big picture and to compare the finest details.

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:

• 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.

• 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.

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.

Business units can represent branches, regions, subsidiaries, functional areas.

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.

You always have the same number of setIDs as you have tablesets. For example, the following diagram shows four control tables. Each color represents a setID, and all rows with the same color represent a tableset, for a total of five tablesets:

Tablesets are rows of data identified by a setID.

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 and, for another group of records, each business unit uses it’s own setID. For the third group of records, one table set is shared for two business units but the third uses the values in another setID:

Table sets can be shared across business units or unique to business units.

See Enterprise PeopleTools PeopleBook: Server Tools

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 setID. You have two options:

• If you want create rows of data in the control tables that should be used only with the new business unit, create a setID for the business unit when you create the business unit.

  When you create a setID at the time you create a business unit, 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 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 a record in the Tableset Control component for the business unit, populated with every record group in the system, and associates with each record group the 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 record the system creates for the business unit in the TableSet Control component. You can change some or all of the setID assignments in this component.

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 set up 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 be determining the following:

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

   USA

2. What table controls data for this field?

   JOBCODE_TBL

3. What record group is that table in?

   HR_02

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

   SHARE

5. What rows in the control table are keyed by that setID?

   The system makes available to the user only the rows keyed by the USA 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:

Tableset sharing process

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

Referencing Multiple SetIDs

Occasionally, some pages have references to two setIDs. 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 has 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.

Department Profile page

In a situation where there are two setIDs for a prompt, you can set up the component so that the system makes available in the Location field:

• All locations in all setIDs.

• Locations only in 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 use 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 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 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, on the Job Data component, select the business unit. The system references the tableset controls for that business unit to determine the valid setIDs for many of the fields on the component:

Select the business unit, which determines the valid setIDs for many fields on the page.

Select the department. The system only makes available departments in the DEPT setID selected for this business unit:

The system only displays values in the setID selected for this field’s prompt table for this business unit.

The system checks to see if the setID of the location associated with the selected department is valid for this business unit. If yes, the system enters the default location in the Location field. If not, the system leaves the Location field blank:

The system only enters the default value if it is in a valid setID for this business unit.

The system checks to see if the setID of the salary plan associated with this location is valid for this business unit:

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

Select a Salary Plan that is valid for the business unit:

You can only select a value with a valid setID.

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 Default 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 Default component.

When a user accesses a component that is driven by business unit defaults and selects a business unit, the system determines which setID drives defaulting for that business unit on the Tableset Control – Record Group page. The system references the Business Unit Options Default component to retrieve the default values you set up for the selected setID and then enters those values in the transaction component. This diagram illustrates this process:

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 Default 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.

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 Default 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