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.

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.

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:

The procedures for accessing and entering information in these component are the same as those for updating any PeopleSoft component.

Working with Business Units

This section provides an overview of business units and discusses how to:

• Determine your business unit structure.

• Implement business units.

• Implement multiple business units.

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.

You can define business units that reflect the needs of your internal human resources departments. For example, you can define business units that group workers according to functional or administrative tasks.

Or, you can define business units that reflect the business structure of your enterprise. For example, you can define a single business unit to represent your entire organization, or you can define several business units to represent various companies, agencies, subsidiaries, divisions, departments, or branch offices within your organization.

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.

If every department uses the same processing rules, your entire organization may have only one business unit. But multinational or otherwise diversified companies, such as those that have multiple cost centers, divisions, or subsidiaries, usually have multiple business units.

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

Each business unit’s HRMS control data, such as department codes, locations, job codes, positions, salary plans and so forth, are stored on the TableSet Control component, which is keyed by business unit. This ensures that the data from one business unit, although it exists in the same physical database table, is always segregated from that of other business units in the organization.

Note. The setID segregates the data in the control tables. Therefore, many business units can share the same set of data on the physical table in your human resources system.

See Also

Control Tables, Transaction Tables and Prompt Tables

Determining Your Business Unit Structure

How you define a business unit depends on your industry, statutory requirements, regulatory reporting demands, or how you’ve organized operating responsibilities. For example, a bank might treat each branch as a business unit, which would mean that the bank could do reporting for its people within each group, by a branch or an office.

Identifying business units for a bank

Another example might be an organization that’s global. Multinational companies might separate their 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.

Identifying business units for a global organization

Some organizations have subsidiary companies. Highly diversified organizations 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.

Identifying business units for an organization with subsidiary companies

Some organizations may want to organize information by functionality or purpose, such as what is going on in Sales versus Customer Service. You can create business units that reflect the administrative needs of your human resources, benefits, and payroll departments.

Identifying business units by functionality

You can also use a combination of all of these methods. Business units don’t necessarily have a restriction, 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.

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

Implementing Business Units

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 person's Job and/or Position 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 a 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 they 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?

Note. When you implement a business unit, you must assign it a setID

Implementing Multiple 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 and administer certain control tables, such as the Department component (DEPARTMENT_TBL) or the Location component (LOCATION_TABLE). 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:

• Share centrally maintained data.

• Reference multiple setIDs.

• Implement tableset sharing.

Understanding Tablesets

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

Tablesets and SetIDs

A tableset is a group of rows (set of data) in a control table that is identified by the same high-level key. A setID is a label (high-level key) that identifies a tableset. There are two types of setIDs:

• A physical setID is a label for a set of data that is identified by the following business rule: BUSINSES_UNIT = SETID. That is, specific rows of data are associated with a specific business unit. The system automatically creates physical setIDs when your enter a business unit into the system.

• A logical setID is a label for a set of data that is identified by some other business rules. Logical setIDs are a way to share rows of data across multiple business units.

The terms tableset and setID are sometimes used interchangeably. In many cases, this is correct, but it can cause some confusion. Remember that a tableset is a group of rows that are identified by the same setID and a setID is the label that identifies a tableset. 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:

Tableset diagram

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

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.

Business Units and SetIDs

When you implement a business unit, you must assign it a setID. You have two options:

• Specify an existing setID to be used as the default.

• Create a new setID. You typically do this when you have only one business unit or when you don’t plan to share data.

Tableset Sharing

Tableset sharing is a device that enables you to share – or restrict – the information stored in control tables across business units. For example, you can centralize redundant information such a country codes while keeping information such as departments and job codes decentralized. 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 page (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.

See Enterprise PeopleTools PeopleBook: Server Tools

Sharing Centrally Maintained Data

If much of your control table data is the same from business unit to business unit, tableset sharing enables you to share that information instead of having to enter the same data multiple times.

Example: Using Business Units and SetIDs to Control Information Flow

Suppose your organization has 10 business units with the same job codes. Enter the job code once and set up tableset sharing.

Tableset sharing also enables you to deal with exceptions within your organization. For example, let’s say that 9 of your 10 business units use the same job codes, but the tenth business unit uses entirely different job codes. You can still use tableset sharing.

So how does this all happen? When a user selects the down arrow on a list box field, the list that appears contains all of the possible, valid entries that can be entered in that field.

The following series of questions outlines the online process that occurs for this to happen:

Tableset sharing process

The rows that are identified by question 5 contain the data that is provided to the user as valid options in the list box.

Tableset sharing is a time-saver, a way to share redundant information among business units. The key to sharing that information is defining what data is available under specific circumstances. To do this, you use setIDs. Tableset sharing consists of assigning specific setIDs to specific record groups for individual business units. A record group is a set of logically and functionally related control tables and views.

Note. 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 table.

Assigning specific setIDs to specific record groups

In questions 4 and 5 in our example, the data from the control tables that is valid in any situation depends on the setID that has been assigned to a record group for the business unit in which the user is currently working. Therefore, you can share information across business units by assigning the same setID to the same record group for each business unit.

Tableset sharing

Tableset sharing is easy for an organization to design. In fact, it is almost entirely set up by the time you finish creating your business units. Most of the setup happens behind the scenes and isn’t obvious. When you create a business unit, that business unit and a default setID are automatically linked to each record group in the system that you are using.

When TableSet Sharing Doesn’t Help

Sometimes you may want to share a limited amount of data among business units while the rest of your data remains unique for each business unit. For example, three of your job codes might be the same for each business unit in your enterprise, but the rest of your job codes might be unique to each business unit. In this case, tableset sharing wouldn’t be useful, and it would be more efficient to enter each job code into the Job Codes component (JOB_CODE_TBL) for each setID.

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

For example, let’s look at DEPT_TBL which has SETID in the key, along with the DEPTID (department ID). It also contains a field called Location, which prompts from the LOCATION_TBL, another setID table.

Department Profile page

In a situation where there are two setIDs for a prompt, which setID should the system use when it displays prompt values for the Location field? You can set the system to display all setIDs for the Location table or you can limit the choices. Showing all setIDs (and all Location values) often creates situations where the Location value that the user selects is not correct for a certain business unit when it is defaulted in at runtime. Consider the following example:

In this example, when a department is part of the SetID USA, there are two different setID options for Location: USA and ASIA. If you allow the locations in the DEPT_TBL field to be selected from any setID, regardless of department ID, setID, and business units, the location that the system defaults into the page is invalid.

Because you can’t predict what the business unit in the transaction table will be, you establish the group of setIDs with which the business unit can be associated. The system won’t default invalid setIDs on transaction tables. If the setID is invalid, then no value is defaulted into the table.

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

Let’s look at the JOB_DATA component that has a default business unit/setID that is associated with the person on the Work Location (JOB_DATA1) page. The default business unit here controls the prompt values that are displayed when you select a department on the Work Location page, based on the setIDs that are associated with that business unit on the TableSet Control - Record Group page (SET_CNTRL_TABLE1). The department that you select may or may not default in the Location, depending on whether the Location SetID is a valid setID value for that business unit. In turn, the Salary Plan default on the Compensation page (JOB_DATA3) is controlled by the Location that you select on the Work Location page. To understand how the defaulting across these different prompt tables in the Job Data pages work, consider the following scenario:

First, you’ve defined the following business units in the TableSet Control - Record Group page:

Next, you’ve set up the department and location components:

Given the preceding TableSet Controls component , Department component, and Location components definitions, when you add a worker into PeopleSoft Enterprise Human Resources using the job data pages, defaulting on the worker's Job record occurs according to the following scenario:

You select Department 10100 USA (a department selected from the departments with the SetID USA). When you move out of the Department field, one of two things can happen. The system first looks at the Department table and finds the default location for Department 10100. It sees that the default location setID for the department is USA. The system then references the TableSet Record Group Controls table.

If USA isn’t a valid setID for the PDEV Location Record Group, then the system doesn’t insert a default into the Location field on the Work Location page. When you prompt for valid locations on the Location field, the system displays only those locations that are associated with the valid setIDs for the PDEV Location Record Group on the TableSet Record Group Control table.

However, because USA is a valid setID for the PDEV Location Record Group, the system inserts the default location for Department 10100 USA, as defined on the Location component this case, Location 001, Corp (Corporate) HQ.

When you select a location with a PDEV SetID and move out of the Location field or accept the Location field default, the system finds the default Salary Plan SetID that you specified on the Location component and defaults in the proper Salary Plan information on the Salary Plan page (JOB_DATA_SALPLAN). In this case, you’ve defined the default Salary Plan SetID as USA and the default Salary Plan as CCB on the Location component, so the default Salary Plan on the Salary Plan page is CCB.

If USA isn’t a valid setID for the PDEV Salary Plan Record Group, then the system does not insert a default value into the Salary Plan field on the Salary Plan page. When you prompt for valid salary plans on the Salary Plan field, the system displays only those salary plans that are associated with valid setIDs for the PDEV Salary Plan Record Group on the TableSet Control - Record Group page.

Implementing TableSet Sharing

Tableset sharing is easy to design and is almost entirely set up by the time you’ve finished creating your business units. Most of this setup happens behind the scenes and isn’t always obvious.

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: (1) they save time by enabling you to set up tableset sharing without an enormous amount of redundant data entry and (2) they act as a safety net by ensuring that tableset sharing is applied consistently across all related tables and views in your system.

When you create a business unit, it is automatically linked to each record group in the system. This is the beginning of tableset sharing.

The beginning of tableset sharing

See Enterprise PeopleTools PeopleBook: Server Tools

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

Once you’ve defined your business units and established your tableset sharing structure, you can associate them with business units and permission lists in your PeopleSoft HRMS system. When a user signs on to the system, defaults and control values throughout PeopleSoft HRMS are based on the defaults that you establish for that user’s permission list on the Primary Permission Lists table. You can do the following:

• Specify unique, default setID and business unit information, along with other fields, such as Company, Country, and Standard Hours, for each permission list.

• Control which default values are placed automatically into the defined fields throughout PeopleSoft HRMS, based on the permission list that users are associated with at the user ID level.

• Share default values among your organization’s business units. The table is keyed by permission list to enable this kind of sharing.

You can also link specific defaults to a business unit setID so that when a user selects a business unit on the tables and pages throughout PeopleSoft Human Resources, the defaults for country and currency (to name just a couple of options) populate the pages automatically, based on the defaults that you establish on the Business Unit HR Defaults table.

See Also

Enterprise PeopleTools PeopleBook: Security Administration

Defining Business Unit HR Defaults

The first time you open a system page, with or without a business unit being associated with it, the field level defaults on the page are loaded from the defaults that you set up for Company, Country, To Currency, and so forth, on the Org Defaults by Permission List component (OPR_DEF_TBL_HR). These defaults are based on the permission list to which the user belongs (at the user ID level). The only time that the default settings on the Business Unit Options Default page (BUS_UNIT_OPT_HR) come into play in determining field level defaults (if you’ve set up business unit HR defaults at all) is when you enter a business unit on a page where the BUS_UNIT_TBL_HR has been specified as the default and move out of the field. When you do that, the system finds the business unit (set control value) on the TableSet Control − Record Group page. The system checks to see what controlling SETID is described for the Business Unit Defaults Record Group (HR_06), goes to the default setID on the Business Unit HR Defaults table, finds any defaults that you specified there, and populates the system page accordingly.

Setting up business unit defaults on the Business Unit HR 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. If this is the case, you can predetermine system defaults for the fields for which you can specify defaults on the Business Unit HR Default page.

Understanding the Difference Between Permission List and Business Unit Defaults

Most of the page-level defaults in the PeopleSoft HRMS system are based on permission list as opposed to business unit. Business unit-based defaults in PeopleSoft HRMS work as follows:

1. The system retrieves the setID for the specified business unit, as defined in the HR_06 record group.

2. Once the system has the setID for that business unit, the system can retrieve the correct data row of default values for that unit, because the Business Unit HR Defaults table is keyed by setID.

In this way, many business units can share the same default values.

Permission list-based defaults have one set of defaults for one permission list. The default setID and business unit for a permission list are normally used to populate values in the relevant fields (for example business snit and setID) on pages and in dialog boxes throughout your system.

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

See Also

Enterprise PeopleTools PeopleBook: Security Administration

Enterprise PeopleTools PeopleBook: Data Administration Tools

Determining System Default Values

To see how the system checks for default values, based on the information that you defined on the Business Unit Options Default page and the Org Defaults by Permission List component, refer to the following table:

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.

Working with Job Data Records

This section provides overviews on JOB records and business units and JOB records and tableset sharing.

Understanding Job Data Records and Business Units

A job data record for a person in PeopleSoft Human Resources can belong to only one business unit. Each Employment Record Number can belong to only one business unit.

Because a worker can fill more than one job in an organization, there might be multiple job data records for a worker that are attached to different business units. For example, an employee of a university could be both a professor (job code 10100 UNI) and a dean (job code 10100 ADMIN). Thus the employee would be in two different job codes and in two different business units (UNI and ADMIN) simultaneously. The only requirement is that the concurrent jobs be in different Employment Record Numbers.

Note. Organizations can point their business units to different sets of codes for each of these control tables. All prompting for these codes in relation to a worker with Job Data is controlled by the person's business unit.