Control Tables, Transaction Tables and Prompt Tables
This chapter discusses:
Control tables, transaction tables and prompt tables.
Business units, tablesets and setIDs.
Effective dates.
Person or position structure.
Note. This chapter introduces you to some of the basic concepts used through PeopleSoft HRMS.
Control Tables, Transaction Tables and Prompt Tables
PeopleSoft HRMS is a table-based system that stores critical general data, such as companies, work locations, and system specifications in a central location. The system enables users to access the same basic information while maintaining data accuracy and integrity.
Tables that are central to PeopleSoft HRMS include control tables, transaction tables, and prompt tables.
Control Tables
Control tables store information that is used to process and validate the day-to-day business activities (transactions) users perform with PeopleSoft HRMS applications.
The information stored in control tables is common and shared across an organization, for example, master lists of customers, vendors, applications, items, or charts of accounts. By storing this shared information in a central location, control tables help to reduce data redundancy, maintain data integrity, and ensure that users have access to the same basic information.
The information stored in control tables is generally static and is updated only when fundamental changes occur to business policies, organizational structures, or processing rules.
Note. Control tables are tables that include the SETID key field (setID). As you set up control tables, you'll notice that it is the setID that enables control table information to be shared across business units.
Transaction Tables
Transaction tables store information about the day-to-day business activities (transactions) users perform with PeopleSoft HRMS applications.
The information stored in transaction tables often changes and is updated more frequently than the information stored in control tables.
Note. Transaction tables are tables that include the BUSINESS_UNIT field (which may or may not be used as a key field).
Prompt Tables
Prompt tables are tables that are associated with fields on PeopleSoft application pages and which display valid data values for those fields when a user selects a prompt or search option.
The data values stored in prompt tables are retrieved from control tables, transaction tables, or other PeopleSoft tables.
See Also
Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer
Business Units, Tablesets and SetIDs
PeopleSoft regulates HRMS system data through the use of business units, tablesets, and setIDs.
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 must define at least one business unit. The BUSINESS_UNIT field is included on all transaction tables.
Tablesets and SetIDs
Tablesets and setIDs are devices that enable you to share – or restrict – information across business units. For example, with tablesets and setIDs you can centralize redundant information such as country codes while keeping information such as departments and job codes decentralized. The overall goal of tablesets and setIDs is to minimize data redundancy, maintain data consistency, and reduce system maintenance tasks.
You must define at least one tableset (setID). The SETID key field is included on all control tables.
See Also
Working with System Data Regulation in HRMS
Effective Dates
PeopleSoft HRMS uses effective dates to store historical, current, and future information. Effective dates enable you to:
Maintain a chronological history of your data. By storing effective-dated information in tables, the system enables you to review past transactions and plan for future events. For example, you can roll back your system to a particular time to perform historical analyses for your company. Or, you can set up tables and data ahead of time without using tickler or pending files.
Maintain the accuracy of your data. By comparing the effective dates in prompt tables to the effective dates on application pages, the system displays only those values that are valid for the current time period. For example, you create a new department code with an effective date of May 1, 2008. Then, on the Job Data pages, you enter a new data row for an employee with an effective date before May 1, 2008. When you select the prompt for the department field, you won't see the new department code because it is not in effect.
See Also
Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer
Person or Position Structure
PeopleSoft HRMS enables you to structure or drive your PeopleSoft Enterprise Human Resources system by person or by position. Before you set up information in the control tables, you must decide which method to use. The system processes the information differently depending on your choice.
What's the Difference?
When you drive PeopleSoft Human Resources by person, you use job codes to classify job data into groups. You use those codes to link person data to job data. When you drive PeopleSoft Human Resources by position, you still use job codes to create general groups, or job classifications, in your organization, such as EEO (equal employment opportunity) and salary survey data, but you also uniquely identify each position in a job code and link people to those positions.
Job codes primarily have a one-to-many relationship with workers. Many workers share the same job code, even though they might perform the work in different departments, locations, or companies, as shown in the diagram below. You identify the job that a worker performs through the data that you enter in the worker's job records:
Driving HRMS by person
In contrast, positions usually have a one-to-one relationship with workers. However, you can have several positions with the same job code; positions track details of a particular job in a specific department or location. For example, in job code 1020, Administrative Assistant, you can define different administrative assistant positions with different position numbers—position 15 in accounting, position 16 in the human resources department, position 17 in your marketing department, and position 18 in your production group. Workers are then assigned to these specific positions. The following diagram represents this method:
Driving HRMS by position
When you drive your system by position, you define specific attributes of various positions and then move workers in and out of those positions. You track specific information that is related to a position, such as a phone number or mail stop, regardless of whether a person actually fills that position. And you use data that is specific to each position as the basis for organization planning, recruitment, career planning, and budgeting.
Why Does It Matter?
You won't see much difference between the two methods as you work with pages and tables, but the system processes the data differently according to whether you drive it by person or position. That affects how and where you enter and maintain data for people and positions (or jobs).
Which Method Should You Use?
To determine whether you should drive your system by person or position, consider the following:
If your organization is fluid (that is, if you tend to look at broader groups of workers and create new jobs often), then driving the system by person is probably best for you.
This method is useful if your organization is continually expanding or if new projects require that you create new jobs or job types regularly.
If your organization is fairly static (that is, if jobs and job descriptions are mostly fixed, and people move in and out of the same positions), then driving the system by position is probably best for you.
For example, government agencies and hospitals, which plan positions based on budgets (often well in advance of filling the positions), find this method very useful.
If you find that both methods work well in different areas of your organization, you can drive PeopleSoft Human Resources both ways.
For example, you might find that driving the system by position works well for some departments or management levels in your company and that driving the system by person works well for others. If so, you can use both methods with a setting called partial position management.
Note. This decision doesn't affect your PeopleSoft payroll system. No matter which method you choose, using PeopleSoft Enterprise Payroll for North America or PeopleSoft Enterprise Global Payroll is not a problem.
Considerations for Pension, Payroll, and Benefits Applications
If you use PeopleSoft Enterprise Pension Administration, you track your pension payees—retirees, beneficiaries, and QDRO (qualified domestic relations order) alternate payees—using the same tables that you use to track your workers. You want to drive your retiree organization by person (or in this case, by payee), rather than by position, so that you don't have to establish a different position for each payee in the system. To drive your worker organization by position and your payee organization by person, use the partial position management option.
This also applies to organizations that use PeopleSoft Global Payroll and PeopleSoft Payroll for North America. If your organization uses the PeopleSoft Human Resources Manage Base Benefits business process or PeopleSoft Enterprise Benefits Administration, you can set up your position management options using full or partial position management.
See Also