Business unit: An identification code that represents a high-level organization of business information.

You can use a business unit to define regional or departmental units within a larger organization. (work force administration-job information-job data see table-1).

Table-1 Effective Date: Date on which a table row becomes effective; the date that an action begins. For example, if you want to close out a ledger on June 30, the effective date for the ledger closing would be July 1. This date also determines when you can view and change the information. Pages or panels and background processes that use the information use the current row. Empl Rcd# (Employee Record Number): A system-assigned number that indicate a person has more than one job data record in the system. When multiple jobs are assigned to a person and he gets paid separately for each job, the employee record no. changes accordingly. For example a person works Monday and Tuesday in Electronics and on other days of the weeks on different jobs in the same company and gets paid differently for each job. It is not a common scenario in the industries, but some for example; universities, library and state government may work in this manner.

Table-2 Pay Group: The group of people in the company who gets paid on the same frequency, such as all the people who get paid weekly on the same day of the week or all salaried people get paid on 1st of every month GL Pay type: Organisation can use this field for customized general ledger interfaces. Payroll for North America does not use this field. This field links HR to finance dept. for the payment of salary of the employee.

Table-3 Salary Administrative plan: This field will default value from the position number (table-1) you associated with a person, and is available for entry regardless if you click the Override Position Data button. The value in this field comes from either the Location or Job Code table, based on the setID matching. You can override the default.

Table-4 Seq (sequence): The sequence number of the rate code if it is used more than once (see table-4). If the employee is paid in two different ways for one or more jobs he is doing with the company. Comp Rate, currency and frequency: The compensation rate, its currency, and the frequency (for example, annually, weekly, or hourly) the comp rate will be paid.

Table-5

Benefit Systems: There are three to choose from (voice file 46:00, 8/18) 1. Base benefits: The user, or the Manager of the employee decides what kind of benefit he should be given. 2. Benefits Administration: The standard format based on the location, position, grade and pay-scale it is automatically calculated by the system. 3. Not managed in People soft: The company follows some other benefits program and does not use which comes with the PS application. Benefit Program: (see table-5) This is like a bucket which contains different benefit plans under it. You can enrol an employee in a benefit program via job data and then benefit participation program and also through Benefits, enroll in a benefit and Assign to benefit program. Plan type: Based on the Benefit program we choose there are different plan types we can have. For example if the employee is getting enrolled in a health benefit plan, he will have options of different plan types compared to when he opts for life and AD/D benefits. 0 Dependent Beneficiary Type: 1. Dependent: The family member who is dependent on the employee for the benefits (a child gets cover under medical benefit from the employee). 2. Beneficiaries: The family member who is eligible to get 401k or insurance payment Setup HRMS: is used to create or modify setup or control data that is used in the entire module to enter the transaction data, for example department codes and job codes. Its like setting up default values in tables for some of the fields which user needs to choose from.

Table-6 During the installation of HRMS (or peoplesoft) we setup these functionality based on companys requirement. By checking the check box in table-6 we assign different functions to be used by the organisation in People soft. Cobra Benefits: Offer from the company to an employee after his termination or retirement for limited period (18 to 36 months) to have access to the benefits (Flexible spending account (FSA) medical care and medical) at the group rate at his cost, which otherwise will have higher premium. Tax update: If there is a change in tax structure in any state, People soft delivers a tax update or a patch which can up used with the existing PS program rather than making a change in the main application. Bundle: If there is any change in the functionality in any modules or update in the application (fix the problem) program PS provides an update called bundle along with the main application. A maintenance pack consists of two or three bundles and tax updates, when you dont need all the bundles (whole new updates released by PS). Row level security: it is security given to restrict the user to access certain rows or fields in a page.

Control Tables (or Setup Tables i.e., PS_EARNINGS_TBL)

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. Control Tables have drop-down lists of selections you will choose from. 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 or Base Table (i.e., PS_PERSONAL_DATA, PS_JOB)

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. A base table stores live data that is continually changing. The table could store information about employees, their dependents, their earnings, taxes, deductions, or benefits. In short, these tables hold the real data, the non-static.

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.

Application Tables (i.e., PSTREENODE)

The PeopleSoft application stores application rules and definitions in application tables. Occasionally these tables temporarily store data in the middle of a process. With few exceptions, these tables store data that is not relevant to the organization. Most of these tables are not discussed in this book since they contain application data, not HR data. System tables often do not include an underscore after the PS prefix.

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 grouping of table (data) that is keyed by the same SetID is called a TableSet. A setID is a label (high-level key) that identifies a TableSet. 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. Most data recorded in control tables is stored by Table Set ID (SetID). Whenever your enter information in control table, you must enter the SetID to establish the

ownership of that information. The SETID table is a delivered PeopleSoft table used to label and identify Tablesets. You must define at least one tableset (setID). The SETID key field is included on all control tables.

Business unit:
One can define Business Units that reflect the specific functional needs of your internal human resources departments, or reflect the actual business structure of your enterprise. Your Business Units may be, for example, companies, agencies, subsidiaries, divisions, departments, or branch offices within your organization. Or, you may choose to have a single Business Unit represent your entire organization. It's up to you and your unique business needs.

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

Record Groups:
In order to share data among different business unit using TableSet feature, all control tables are divided into Record Groups. So, we group control tables to form something called as Record Groups. The control tables used by each of the HRMS applications are grouped by function into record groups. A record group is a set of logically and functionally related control tables and views. All tables in the same record group will have the same key on each table. Once you have created a SetID and Business Unit, you need to map a relationship between this two using the record groups. With this you will determine which SetID you want the system to access for each of the above delivered record groups for HR or PY for each business unit. So, when you create a business unit, the system creates an entry 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 that you selected for the business unit. For Example, if we have created a business unit as ABCBU and mapped SetID as TSTID, at the TableSet Control component for ABCBU, it should have TSTID as the SetID mapped to all available record groups

Table-8 All of these values defaulted from the business unit setup. Here you can modify the mapping of SetID to each individual record group, i.e. when 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. So, based on this setups, when you open a Transactional page like Job Data, and you try to query any Control Table Based prompt fields like Location, Department or Job Code, you will get the results based on the Business Unit and the SetID

Combination that was set in Set Control Page. So for example, if you have Location Table with 10 rows, 8 rows had TSTID as the SetID and 2 rows with USA01, and if you have ABCBU as the business unit in the Job Page, you should see 8 rows of Location Data when you click on the Prompt Table of Location Field. 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:

Table-9 This table-10 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-10

PeopleSoft Security PeopleSoft security is based on permission lists and roles. This diagram illustrates how permission lists are assigned to roles and then roles assigned to user IDs to create user security profiles:

Table-11

To administer security:
1. Create permission lists. 2. Create roles and attach permission lists to roles. 3. Create user IDs and attach permission lists and roles to user IDs. Create 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. This level of access should be appropriate to a narrowly defined and limited set of tasks, which can apply to a variety of users with a variety of different roles. These users might have overlapping, but not identical, access requirements.

You typically define permission lists before you define roles and user profiles. When defining permission lists, however, consider the roles that you will use them with.

The diagram represents the security authorizations of Tom Sawyer. Mr Sawyer inherits the five permission lists that are assigned to the two roles that are assigned to his user profile. In this example, he has access to the employee self-service pages, the service monitor, PeopleSoft Process Monitor, and PeopleTools Security. If Tom were to become a manager, then the permission lists assigned to the Manager role would be added to his profile. We can create permission lists and assign to them access to menus, components, component interfaces, pages, global functionality, along with other information. Permission lists are assigned to roles; however, some permission lists are assigned directly to the user. We can create permission lists using the Permission Lists component or Copy Permission Lists component by navigating to PeopleTools, Security, Permissions & Roles and selecting the appropriate component.

Table-12 Note. Assign data permission to permission lists on the Security by Dept Tree page and the Security by Permission List page by navigating to Set Up HRMS, Security, Core Row Level Security and selecting the appropriate component. Define roles. Roles are intermediate objects that link user profiles to permission lists. You can assign multiple roles to a user profile, and you can assign multiple permission lists to a role. Some examples of roles might be Employee, Manager, Customer, Vendor, and Student. A manager is also an employee and may also be a student. Roles enable you to mix and match access appropriately. You have two options when assigning roles: assign roles manually or assign them dynamically. When assigning roles dynamically, you use PeopleCode, LDAP, and PeopleSoft Query rules to assign user profiles to roles programmatically.

Define user profiles. User profiles define individual PeopleSoft users. Each user has an individual user profile, which in turn is linked to one or more roles. You add one or more permission lists, which ultimately control what a user can and cannot access, to each role. A few permission types are assigned directly to the user profile.

Typically, a user profile must be linked to at least one role in order to be a valid profile. The majority of values that make up a user profile are inherited from the linked roles. You typically define user profiles after defining their roles. You can assign a given role to multiple user profiles. It's worthwhile to define a set of roles that you're confident can be assigned to user profiles that you'll create in the future.

Table-13 In addition to the permission lists assigned to roles, the following four specific permission lists ( table-13) are assigned directly to the user on the User Profile General page by navigating to PeopleTools, Security, User Profiles, User Profiles, General. Unlike the permission lists assigned to roles, users can have only one each of these four permission lists: 1. Navigator Homepage: Navigation homepages are used by PeopleSoft Workflow. 2. Process Profile: If a particular user must run batch processes using PeopleSoft Process Scheduler, assign the appropriate process profile to the user profile and create process groups for your processes. A user receives both process group and process profile authorizations through permission lists. A user gets permission to process groups through roles, and they get a process profile through the process profile permission list. Process profiles contain PeopleSoft Process Scheduler authorizations. 1. Primary: Primary permission lists grant global security. 2. Row Security: Row Security permission lists grant data-permission security based on a department security tree. Assign data permission to permission lists on the Security by Dept. Tree page.

Symbolic id: The id used by peoplesoft internally to get into the database when a user logs in using his user id at the front end to look for some data. For example when a user enters a data in the dependent table to look for dependent information, the application uses this symbolic id, not the id which he used to log in to peoplesoft to get into the DB and get the data into the application.