Introduction to PeopleSoft Fundamentals

PeopleSoft Fundamentals Introduction
PeopleSoft Fundamentals
PeopleSoft application runs on PeopleSoft Pure Internet Architecture, which requires a variety of software
and hardware elements:
 A relational database management system (RDBMS) server.
 An application server.
 A batch server.
 A web server.
 A web browser.
It’s important to understand the role of each element before you can decide which configuration will work
best for your implementation of PeopleSoft Pure Internet Architecture. The following diagram illustrates, at
a high level, the physical relationship between PeopleSoft Pure Internet Architecture elements:
High-level PeopleSoft Pure Internet Architecture relationships

Configuring PeopleSoft Pure Internet Architecture is not just about enabling internet application
deployment through a browser. PeopleSoft Pure Internet Architecture enables you to take advantage of all
PeopleSoft intranet and internet solutions, as well as PeopleSoft integration technologies such as
PeopleSoft Integration Broker.
Database Server
The database server houses a database engine and your PeopleSoft application database, which
includes all the application’s object definitions, system tables, application tables, and data. The database
server must be running one of the PeopleSoft-supported RDBMS and operating system combinations.
A single database server can have multiple application servers connecting to it.
Application Server
The application server is the core of PeopleSoft Pure Internet Architecture; it runs business logic and
issues SQL to the database server. An application server consists of numerous PeopleSoft services and
server processes. Just as different elements make up the physical environment in which an application
server operates, such as database servers and web servers, a variety of elements operate on the
application server, enabling it to respond effectively to a multitude of transaction requests and handle
transaction processing, system scaling, browser requests, and so on.
An application server maintains the SQL connection to the database for browser requests and the
PeopleTools development environment in Microsoft Windows.
Domains
An application server domain is the collection of server processes, supporting processes, and resource
managers that enable connections to the database. You configure an application server domain using the
PSADMIN utility located in the PS_HOME\appserv directory on the application server.
PSADMIN creates a directory beneath PS_HOME\appserv for each application server domain that you
configure. When you boot an application server domain, it starts the set of server processes associated
with that domain, such as PSAPPSRV, PSQCKSRV, and PSSAMSRV. Each server process establishes a
persistent connection to a PeopleSoft database, and this connection acts as generic SQL pipeline that the
server process uses to send and receive SQL.
PeopleBooks
PeopleBooks are the official documentation supplied by PeopleSoft. Basic understanding of the
PeopleSoft Applications and Tools supplied by PeopleSoft is provided in the form of web pages.
PeopleBooks need to be configured in the system and then use while development. PeopleBooks are
available in the internet also at various sites.
Sample Web Reference URL: http://peoplebooks.cognizant.com/
There are two Broad categories of PeopleBooks:
1. PeopleTools
2. Functional Module wise Documentation
Activity:
Table: JOB
Fields: EMPLID, COMPANY, DEPTID, STD_HOURS
1. Select all employees of company 001?

a. Select EMPLID from JOB where company = 001
2. Select all employees with standard hours <= 40?
a. Select EMPLID from JOB where STD_HOURS <= 40
3. Insert sample data into JOB?
a. Insert into JOB (EMPLID, COMPANY, DEPTID, STD_HOURS) values (1234, 001,
‘ABCD’, 40)
How to start Application Server?
Follow below sequence of instructions to start an application server.

Choose either parallel or serial Boot. It makes no difference for start up. When the server is starting it will
start all its sub servers’ one after the other.
How to Stop Application Server and Clear Cache?
We need to clear cache sometimes when the Application Server is not responding or when it is not
connecting from online or when we get message saying that the application server is down
Clear Cache in the application server and in the client’s local profile at below locations:
Fundamentals of HRMS
1. Personal Model:
Organizations have relationships with a variety of people for a variety of reasons. PeopleSoft enables
you to manage the data of those people with whom you have an organizational relationship. A person
can have more than one organizational relationship at any one time or can change relationships over
time.
Organizational relationships fall into one of the following categories:

 Employee.
A person who is hired to provide services to the organization and has a legal employee
relationship with the organization
 Contingent worker.
A person who provides services to the organization and who does not have a legal employee
relationship with the organization
 Person of interest (POI)
A person who is not an employee or contingent worker but is of interest to the organization
POIs can be:
 COBRA participants.
 Pension payees.
 Stock - board members.
 Stock - non-HR administered employees.

 External trainees
 External instructors
 Any person who fits within a POI type you’ve created.
 Applicants who require payment through Payroll for North America prior to being
hired.
Action Date Employment Instance Contingent Worker Instance POI Instance
March 1, 1997 POI instance created.
April 7, 1997 POI instance job

record deactivated.
April 7, 1997 Employment instance created

with this date as the hire date.
May 1, 1998 No change to employment job Contingent worker instance created with this as the
record. hire date.
June 15, 1998 Transferred departments No change to the contingent worker job record.
December 15, No change to employment job Contingent worker job ends and the job data record
1999 record. is deactivated. This date is the termination date for
this instance.
March 1, 2001 Promoted.
Action Date Employment Instance Contingent Worker Instance
May 1, 1996 Employment instance created. Job record identified by:

 ID: 8901
 ERN: 0
 Organizational relationship: employee
May 1, 1998 Substantive job suspended.
May 1, 1998 New job record for temporary assignment created. Job
record identified by:
 ID: 8901
 ERN: 1
 Organizational relationship: employee
November 1, Temporary assignment completed.

1998
November 1, Substantive job resumed.

1998
February 1, No change to employment job record. Contingent worker instance created. Job record
Action Date Employment Instance Contingent Worker Instance
1999 identified by:

 ID: 8901
 ERN: 2
 Organizational relationship: contingent
worker
This diagram illustrates Jan Smith’s job records under the organizational relationships:
Jan Smith’s job records from May 1, 1996 to February 1, 1999
2. Job Information:
Entire job information of the worker is stored in Job Data component. This contains six pages and three
secondary pages. Majority of the information is stored JOB table.
Study PeopleBooks:
 What is Effective Date?
 What is Position Structure?
 What is Business Unit?
 What is Job Code?
 What is Salary Admin Plan?
Table Name
PS_JOB EMPLID  Key: Employee ID stores identification number of employees
(persons)
EMPL_RCD  Key: Employee Record tracks the multiple jobs of an

employee. It starts with zero.
EFFDT  Key: Effective date tracks the job changes across life of
employee. It helps maintain current and future changes of an employee’s
job without loosing historical information
EFFSEQ  Key: Effective Sequence helps in storing changes on same

day. Employee getting transferred and then moving on to an unexpected
leave of Absence due to illness.
ACTION: Action stores change happened to employee’s job. Hire,

termination, Retire, Leave, Promotion, etc
ACTION_REASON: Action Reason stores reason behind an action. It can

be blank also. Hire action, for example, can be because of new position,
Position restructuring, etc
COMPANY: The legal entity to which the employee works for and is paid by.
STEID_ LOCATION /LOCATION: It refers to the location code where the

employee is working.
SETID_DEPT/DEPTID: The department to which employee works for.

Department is subset of a company.
BUSINESS_UNIT: Business Unit is the logical separation of enterprise in

PeopleSoft. This helps share the setup structure across various business
units and maintain the similar standards.
REG_REGION: Regulatory Region is the geographical unit which is bound

to common laws and legal rules. Every employee belongs to a regular
region. This is useful of MNC enterprises where country specific regulatory
rules need to b applied for business processing logic
POSITION_NBR: The position which the employee holds in the

department.
SETID_JOBCODE/ JOBCODE: The jobcode is a unique code that

associates with a specific job in the organization. Jobcode can be linked to
many positions. Where as one position can hold only one jobcode.
Entry dates that are stored in JOB:

DEPT_ENTRY_DT,
JOB_ENTRY_DT,
POSITION_ENTRY_DT,
GRADE_ENTRY_DT,
STEP_ENTRY_DT
PER_ORG: There exist three types of relationships for persons with

organization. Employees, Person of Interests, and Contingent workers.
HR_STATUS: This represents if the person is still active in the organization

or not. A for active and I for inactive
EMPL_STATUS: This presents detailed status of the person. Is the person

Active in payrolls, Leave of absence, leave with Pay, Suspended,
Terminated, Retired with pay (Q), Retired, Deceased, etc.
EMPL_CLASS: This shows whether employee is Local, International

Transferee, Expat, etc.
EMPL_TYPE: Employee type determines whether employee is Salaried,

Hourly or Exception hourly in type. Employees of type H & E enter their
work hours in Time &Labor. Accordingly they will be paid. However salaried
employees will receive fixed salary on monthly after applying the payroll
conditions like leaves, bonuses, shift allowances, etc.
OFFICER_CD: This determines the position of the officer like Director,

Chairman, Secretary, Vice president, President, etc. This is set to None or
blank for normal employees.
REG_TEMP: Is the employee Regular worker or Temporary worker.
FULL_PART_TIME: Used to determine whether Full time worker or Part

time worker.
SETID_SALARY/SAL_ADMIN_PLAN: Salary administration plan to which

the employee belongs. This plan is normally setup at
country/department/company levels. Suppose Finance department might
have salary structures different from Marketing departments. Again
marketing department in India might be differently paid compared to US.
GRADE/STEP: Grades and Steps are the part of Salary admin plan which
helps understand the employee salary range and pay structure in the
organization.
PAYGROUP: A pay group is a logical grouping of qualifying individuals for

payment and contains payees who share pay characteristics. All payees in a
pay group must have the same pay frequency (begin, end, and payment
dates) and payroll calculation process and belong to the same pay entity.
HOLIDAY_SCHEDULE: Used to determine the holiday schedule of the

workers.
SHIFT: Shift is used to find out whether worker comes in 1 st, 2nd, 3rd,
Rotating, Not Applicable, Compressed shifts. For general shifts use Not
Applicable.
BAS_GRUOP_ID: Benefits Administration System Group ID is used to

identify employees in groups while processing benefit rules during daily
maintenance.
ELIG_CONFIG1, ELIG_CONFIG2, …, ELIG_CONFIG9: These fields are

used to recognize specific sets of employees during benefits processing in
Eligibility rules. For example if a company ABC acquired another company
XYZ and XYZ only is paid of medical insurance then identifying the
employees of XYZ in benefits can be done by setting one of the ELIG fields
to XYZ.
PS_JOB_JR This contains same keys as that of JOB

This record holds regional specific job data like for Japan, Mexico, Italy, UK,
etc.
PS_JOB_EARNS_DIST This contains same keys as that of JOB + 8 more keys like ACCT_CD,
DEPTID, JOBCODE, etc
This is used to track how employee's earnings should be posted for
accounting purposes? For example, earnings can be posted to a job code,
a department, a location, a General Ledger account, a position, or
distributed among several categories. For example, an employee’s bonus
might be 60% accounted to department A and 40% accounted to another
department B
PS_COMPENSATION This contains same keys as that of JOB + two additional keys called
COMP_EFFSEQ and COMP_RATECD. These are used to track
compensation rates of the employee. Other fields are:
COMPRATE: Compensation amount agreed by the worker

COMP_PCT: Compensation Percent
COMP_FREQUENCY: Frequency for which the compensation applies to.
For ex, COMPRATE of 400,000 per Annual frequency is to say, the worker
receives 400,000 per year.
BEN_PROG_PARTIC These two are additional tables that Job data contains. They store
EMPLOYEMENT additional data required for Benefits and Core HR respectively.
3. Personal Details:
Personal data of workers is stored in the time while a person is added into the system. Since then for
regular maintenance we can use Modify Person page for tracking the personal changes of the
workers. There are various sub-folders in the Personal Information folder too; these are used to track
the personal information more effectively.
Modify Person is the most widely referred place for finding out personal details ranging from most
individual till regional related like Date of birth, Gender, Marital status, ethnicity, military status, etc.
Now let us closely look at USA and IND regions under regional page.
Tabular Related Information:

Table Name Details of Fields
PS_PERSON EMPLID  Key
BIRTHDATE
BIRTHCOUNTRY
BIRTHPLACE
BIRTHSTATE
DT_OF_DEATH
This is the parent table of the personal information. It stores information

about birth details and date of death.
PS_NAMES EMPLID  Key

NAMES_TYPE  Key
EFFDT  Key
EFF_STATUS
COUNTRY_NM_FORMAT
NAME
NAME_PREFIX
NAME_SUFFIX
LAST_NAME
FIRST_NAME
MIDDLE_NAME
NAME_DISPLAY
NAME_FORMAL
Name table stores all types of names of person including Primary (PRI),
Professional, Degree, etc. Name is given specific format based on country.
PS_PERS_DATA_EFFDT EMPLID
EFFDT
MAR_STATUS
MAR_STATUS_DT
SEX
HIGHEST_EDUC_LVL
LANG_CD
ALTER_EMPLID
Personal details which are effective dated like marital status and highest
education level are stored here. Also we have gender of the person tracked
in the same table.
PS_PERS_NID EMPLID  Key
COUNTRY
NATIONAL_ID_TYPE
NATIONAL_ID
SSN_KEY_FRA
PRIMARY_NID
TAX_REF_ID_SGP
Personal Identity information related to person’s country regulations are
stored here. In India we can track Driver License, PAN number, Passport
number etc. In US, we can track SSN, and SIN etc. Also we can track new
national ID types in a country if our customer needs. This is possible in
National ID types setup page.
PS_ADDRESSES EMPLID  Key
ADDRESS_TYPE  Key
EFFDT  Key
EFF_STATUS
COUNTRY
ADDRESS1
ADDRESS2
ADDRESS3
ADDRESS4
CITY
STATE
POSTAL
REG_REGION
Addresses are various types: HOME, MAIL, BUSN, etc. All addresses need
Address1 mandatorily. Also the country field determines type of the address
fields required for the address. For example, County (is equal to our
Mandals) is used in US but not India. Custom address types
PS_PERSONAL_PHONE EMPLID  Key
PHONE_TYPE  Key
COUNTRY_CODE
PHONE
EXTENSION
PREF_PHONE_FLAG
Personal Phone details are tracked. Various types including HOME, BUSN,
CELL, Guest House, etc are allowed. This is not Effective dated
Custom types can also be added in translates of Email Address types
through App Designer.
PS_EMAIL_ADDRESSES EMPLID
E_ADDR_TYPE
EMAIL_ADDR
PREF_EMAIL_FLAG
Email Addresses like BUSN, Personal, Official, etc types are allowed.
Custom types can also be added in translates of Email Address types
through App Designer.
4. Data Organization:
o Purpose of tables in a database:
Observe below data of a company. Imagine that this is stored in an excel sheet like shown below.
EMPLID COMPANY COMPANY_NAME COM_HQ_ADDR LOCATION

1234 KCY Kenya Company Yielding Kenya, 500049 KC0001
Here it is clear that the employees are all storing Company head quarter and company name
again and again unnecessarily. Instead we could have maintained a separate sheet for company
data and a separate sheet for employee data like below:
Employee data:
EMPLID COMPANY LOCATION
1234 KCY KC0001
1236 KCY KC0001
1238 KCY KC0001
1237 KCY KC0002
1235 KCY KC0002
1239 KCY KC0002
Company Data:
COMPANY COMPANY_NAME COM_HQ_ADDR
KCY Kenya Company Yielding Kenya, 500049 50000
GBI Global Business Installs New Delhi, India 50004
So it is clear that storing relevant information will make data easy for understanding (retrieval)
and maintenance (manipulations).
What is relevant population?
A table of Employee data might contain only the company, location, department to which the
employee belongs to. But storing the company data and location data, etc can be better kept
separately.
Employee: EMPLID COMPANY LOCATION

Company: COMPANY COM_NAME COM_HQ_ADDR
Location: LOCATION LOCA_NAME LOC_ADDRESS
o What is a key? What is the use of having multiple keys like it is in Job Data?
What is a record? Collection of fields is a record. It is a logical grouping of data.

What is a field? Basic element of data which can not be further split
What is a Key? Key is a feature which is most striking in the population. It helps identifying the
data uniquely in the population.
12340200901010HIRNPSGBI  Data unorganized
1234 0 2009-01-01 0 HIR NPS GBI  Data organized

1235 0 2009-01-01 0 HIR NPS GBI
1236 0 2009-01-01 0 HIR NPS GBI
1237 0 2009-01-01 0 HIR NPS GBI
Murty 0 2009-01-01 0 HIR NPS GBI  Data organized

Yash 0 2009-01-01 0 HIR NPS GBI
Manoj 0 2009-01-01 0 HIR NPS GBI
Murty 0 2009-01-01 0 HIR NPS GBI
Using Name we can not identify the persons uniquely. Also using date of birth and other fields will
have similar problem. Instead EMPLID will serve better to track if it is allotted uniquely for
persons.
EMPLID is a key to identify above rows
1235 0 2009-01-01 0 HIR NPS GBI

1235 0 2009-05-01 0 POS ACQ GBI
1235 0 2009-12-01 0 PAY MER GBI
1235 0 2009-12-31 0 XFR KCY
1235 0 2010-06-01 0 PAY MER KCY
EMPLID + EFFDT is a key
1235 0 2010-06-01 0 DTC KCY Clerk

1235 0 2010-06-01 1 DTC KCY Clerk Senior
EMPLID + EFFDT + EFFSEQ is a key
Imagine a situation without tracking EFFDT and EFFSEQ.
1235 0 HIR NPS GBI 1

1235 0 POS ACQ GBI 2
1235 0 PAY MER GBI 3
1235 0 XFR KCY 4
1235 0 PAY MER KCY 5
1235 0 LOA FML KCY 6
It is evident that we can not track all rows of an employee with only EMPLID as a key. We need
another supporting Key to EMPLID to store multiple changes of the employee. Also just by having
a mere counter it makes no sense and we can not afford to maintain hire date, position change
date, leave date, etc separately.
1235 0 2010-06-01 0 DTC DTC KCY Clerk

1235 0 2010-06-01 1 DTC DTC KCY Clerk Senior 300000
1235 1 2010-08-01 0 HIR KCY Data Entry Expert 200001
The combination of EMPLID + EMPL_RCD + EFFDT + EFFSEQ is a key in JOB
Other fields like Action, Action Reason, Company, etc can not be keys because they are all
common information and repeat for majority of the employees. For Ex: Every employee gets
hired; so ACTION can not be a key. Every employee belongs to one or other company. In other
words, a company will have lot of employees. So Company itself can not be a key in Employee
table
1235 0 2009-01-01 0 HIR NPS GBI

1235 0 2009-05-01 0 POS ACQ GBI
1235 0 2009-12-01 0 PAY MER GBI
1235 0 2009-12-31 0 XFR KCY
1235 0 2010-06-01 0 PAY MER KCY
1234 0 2009-01-01 0 HIR NPS GBI
1236 0 2009-01-01 0 HIR NPS GBI
1237 0 2009-01-01 0 HIR NPS GBI
5. Data Processing:
Data is stored in data base in the form of tables. Once stored; we can maintain data by updating
where required, and delete rows of data if required.
o Insert data for the employee
INSERT INTO PS_JOB (EMPLID, EMPL_RCD, EFFDT, EFFSEQ, ACTION, …….)

VALUES (1234 , 0 , 2009-01-01, 0 , HIR, ………….)
INSERT INTO PS_JOB

(EMPLID,
EMPL_RCD,
EFFDT,
EFFSEQ,
ACTION, …….)
VALUES
(1234,
0,
‘2009-01-01’,
0,
‘HIR’, ………….)
o Update the data for the employee
UPDATE PS_JOB SET JOBCODE =‘Data Entry’ WHERE EMPLID = 1235 AND EMPL_RCD =1
AND EFFDT = ‘2010-08-01’ AND EFFSEQ = 0
UPDATE PS_JOB SET ACTION_REASON =‘DTC’ WHERE EMPLID = 1235 AND EMPL_RCD
=1 AND EFFDT =‘2010-06-01’
UPDATE PS_JOB SET ACTION_REASON =‘DTC’ WHERE EMPLID = 1235 AND EMPL_RCD
=1 AND EFFDT = ‘2010-06-01’ AND EFFSEQ IN (0, 1)
UPDATE PS_JOB
SET JOBCODE =‘Data Entry’, SENIORITY_LEVEL =‘Expert’
WHERE EMPLID = ‘1235’ AND EMPL_RCD =1 AND EFFDT = ‘2010-08-01’ AND EFFSEQ = 0
o Delete the row for the employee
DELETE FROM PS_JOB

WHERE EMPLID = ‘1235’ AND EMPL_RCD =0 AND EFFDT =‘2010-06-01’ AND EFFSEQ = 0
DELETE FROM PS_JOB

WHERE EMPLID = ‘1235’
o Data Selection of employee’s job information
SELECT * FROM PS_JOB

SELECT EMPLID, EMPL_RCD, EFFDT, EFFSEQ, ACTION, ACTION_REASON, COMPANY
FROM PS_JOB
o Table Creation
CREATE TABLE PS_JOB (EMPLID CHAR(11) NOT NULL,

EMPL_RCD SMALLINT NOT NULL,
EFFDT PSDATE NOT NULL,
EFFSEQ SMALLINT NOT NULL,
PER_ORG CHAR(3) NOT NULL,
DEPTID CHAR(10) NOT NULL, …….,
LASTUPDOPRID CHAR(30) NOT NULL)
o Table Drop
DROP TABLE PS_JOB
6. How to join tables? Rules:

 Whenever data is required from multiple tables; we can use JOIN predicate to select data quickly
and in a better form
 JOIN must be used between similar tables only allowing at least one of the table’s keys are
mapped to another table.
 Use of JOIN: All the keys in both tables that are similar should be joined. If there are no matching
keys; then it will result into Cartesian product.
o Consider Cartesian product between below to tables of Head Count and Grade:
Grade
B
PeopleSoft Fundamentals Head Count Introduction
40
25
Grade Head Count

A 40
A 25
B 40
B 25
o SELECT A.HEAD_COUNT, B.GRADE FROM HEAD_CNT_TBL A, GRADE_TBL B
Grade Head Count

A 40
A 25
B 40
B 25
 While Joining Keys; do not join all keys even if matching, unnecessarily. We need to use our
judgment.
 While joining Keys; you should have mapped all the higher level keys of at least one table
 Types of Joins:
o SIMPLE JOIN or JOIN or INNER JOIN: Return rows when there is at least one match in
both tables
o LEFT OUTER JOIN: Return all rows from the left table, even if there are no matches in
the right table.
o RIGHT OUTER JOIN: Return all rows from the right table, even if there are no matches
in the left table.
o FULL OUTER JOIN: Return rows when there is a match in one of the tables
 Consider a situation where we are joining two tales PS_JOB and PS_NAMES to get employee
job details along with name of the employee.
PS_JOB PS_NAMES
EMPLID  Key EMPLID  Key
EMPL_RCD  Key NAME_TYPE  Key
EFFDT  Key EFFDT  Key
EFFSEQ  Key NAME
ACTION NAME_PREFIX
ACTION_REASON NAME_SUFFIX
COMPANY
LOCATION
DEPTID
POSITION_NBR
BUSINESS_UNIT
DEPT_ENTRY_DT
 JOIN:
SELECT A.EMPLID, A.EMPL_RCD, A.EFFDT, A.EFFSEQ, A.ACTION, A.COMPANY, A.DEPTID,

B.NAME_TYPE, B.EFFDT, B.NAME, B.NAME_PREFIX, B.NAME_SUFFIX
FROM PS_JOB A, PS_NAMES B
WHERE A.EMPLID = B.EMPLID
AND A.EFFDT = ( SELECT MAX(A1.EFFDT) FROM PS_JOB A1
WHERE A1.EMPLID = A.EMPLID
AND A1.EMPL_RCD = A.EMPL_RCD
AND A1.EFFDT <= GETDATE())

AND A.EFFSEQ = ( SELECT MAX(A2.EFFSEQ) FROM PS_JOB A2
AND A2.EFFDT = A.EFFDT)
AND B.EFFDT = ( SELECT MAX(B1.EFFDT) FROM PS_NAMES B1
WHERE B1.EMPLID = B.EMPLID
AND B1.NAME_TYPE = B.NAME_TYPE
AND B1.EFFDT <= GETDATE())
AND B.NAME_TYPE = ‘PRI’
 LEFT OUTER JOIN:

Consider that we want to fetch all employees’ job data and their names which are primary in type
and of course, if there is a non-primary name (Degree name, professional name, maiden name,
etc) then that also should be printed.
In such a case we should join NAMES with itself (self JOIN) with the left side NAMES table to
select PRI names and right side table to select non primary names.
We need to remember one thing here. All employees will have PRI (Primary) name defined; but
defining additional names is optional only. So we need to use LEFT OUTER JOIN here in this
situation to bring all employees irrespective of whether they have non-primary names or not.
SELECT A.EMPLID, A.EMPL_RCD, A.EFFDT, A.EFFSEQ, A.ACTION, A.COMPANY, A.DEPTID,

B.NAME_TYPE, B.EFFDT, B.NAME, C.NAME_TYPE, C.EFFDT, C.NAME
FROM PS_JOB A, PS_NAMES B LEFT OUTER JOIN PS_NAMES C ON B.EMPLID =
C.EMPLID AND C.NAME_TYPE <> 'PRI'
AND C.EFFDT = ( SELECT MAX(C1.EFFDT) FROM PS_NAMES C1
WHERE C1.EMPLID = C.EMPLID
AND C1.NAME_TYPE = C.NAME_TYPE
AND C1.EFFDT <= GETDATE())
WHERE B.EFFDT = ( SELECT MAX(B1.EFFDT) FROM PS_NAMES B1
WHERE B1.EMPLID = B.EMPLID
AND B1.NAME_TYPE = B.NAME_TYPE
AND B1.EFFDT <= GETDATE())
AND B.NAME_TYPE = 'PRI'
AND A.EMPLID = B.EMPLID
ORDER BY A.EMPLID
 Joins further explored: Let us try to get joining of Addresses and Phones of workers. All workers
who have same phone type (Ex: HOME) as that of Address type (Ex: HOME) need to be
returned.
SELECT * FROM PS_PERSONAL_PHONE WHERE EMPLID ='0030'
Let us imagine below sample data:
0030 HOME 040-44562345

0029 CELL 09885202431

0029 HOME 040-45712345
SELECT * FROM PS_ADDRESSES WHERE EMPLID ='0030'
SELECT ISNULL(A.EMPLID,B.EMPLID) AS EMPLID, A.PHONE_TYPE, A.PHONE,

B.ADDRESS_TYPE, B.ADDRESS1, B.CITY, B.STATE, B.COUNTRY
FROM PS_PERSONAL_PHONE A FULL OUTER JOIN PS_ADDRESSES B
ON A.EMPLID = B.EMPLID AND A.PHONE_TYPE = B.ADDRESS_TYPE
WHERE B.EMPLID ='0030' OR A.EMPLID ='0030'
SELECT B.EMPLID, A.PHONE_TYPE, A.PHONE, B.ADDRESS_TYPE, B.ADDRESS1, B.CITY,

B.STATE, B.COUNTRY
FROM PS_PERSONAL_PHONE A RIGHT OUTER JOIN PS_ADDRESSES B
ON A.PHONE_TYPE = B.ADDRESS_TYPE AND A.EMPLID = B.EMPLID
WHERE B.EMPLID ='0030'
SELECT A.EMPLID, A.PHONE_TYPE, A.PHONE, ISNULL(B.ADDRESS_TYPE, ' ') AS TYPE,

ISNULL(B.ADDRESS1, ' '), ISNULL(B.CITY, ' '), ISNULL(B.STATE, ' '), ISNULL(B.COUNTRY, ' ')
FROM PS_PERSONAL_PHONE A LEFT OUTER JOIN PS_ADDRESSES B
ON A.PHONE_TYPE = B.ADDRESS_TYPE AND A.EMPLID = B.EMPLID
WHERE A.EMPLID ='0030'
SELECT A.EMPLID, A.PHONE_TYPE, A.PHONE, B.ADDRESS_TYPE, B.ADDRESS1, B.CITY,

B.STATE, B.COUNTRY
FROM PS_PERSONAL_PHONE A, PS_ADDRESSES B
WHERE A.EMPLID ='0030' AND A.EMPLID = B.EMPLID AND B.ADDRESS_TYPE =
A.PHONE_TYPE
7. GROUP BY & HAVING

Group by construct is used in Selects. This is used to get aggregate information of the data like
Sum, Minimum, Maximum, Average, Count, etc
Having construct is equal to where conditions. However, having is used to build where clause on
GROUP BY aggregated fields only. So, having comes only if there is a group by condition
SELECT A.EMPLID, A.EMPL_RCD, A.COMPRATE

FROM PS_JOB A
WHERE A.EFFDT = ( SELECT MAX(A1.EFFDT) FROM PS_JOB A1
AND A.EMPLID ='K0HU10 '
K0HU10 0 3033.333333
K0HU10 1 3120.000000
SELECT A.EMPLID, SUM(A.COMPRATE)

FROM PS_JOB A

AND A.EMPLID ='K0HU10 '
GROUP BY A.EMPLID
K0HU10 6153.333333
SELECT A.EMPLID, SUM(A.COMPRATE)

FROM PS_JOB A
GROUP BY A.EMPLID
HAVING SUM(A.COMPRATE) > 5000
SELECT A.DEPTID AS DEPARTMENT, COUNT(A.EMPLID) AS HEAD_COUNT

FROM PS_JOB A
WHERE A.EFFDT =( SELECT MAX(A1.EFFDT) FROM PS_JOB A1
AND A.EFFSEQ =( SELECT MAX(A2.EFFSEQ) FROM PS_JOB A2
GROUP BY A.DEPTID
HAVING COUNT(A.EMPLID) >= 10
ORDER BY A.DEPTID
8. Activity 1:
 Select employees whose name contains letter M

SELECT * FROM PS_NAMES A
WHERE A.EFFDT = ( SELECT MAX(A1.EFFDT) FROM PS_NAMES A1
AND A1.NAME_TYPE = A.NAME_TYPE
AND A1.EFFDT <=GETDATE())
AND UPPER(A.NAME) LIKE '%M%'
 Select employees whose address is HOME
SELECT * FROM PS_ADDRESSES A
WHERE A.EFFDT = ( SELECT MAX(A1.EFFDT) FROM PS_ADDRESSES A1
AND A1.ADDRESS_TYPE = A.ADDRESS_TYPE
AND A.ADDRESS_TYPE ='HOME'
 Select employees who do not have HOME Address defined
SELECT A.EMPLID FROM PS_JOB A

AND NOT EXISTS ( SELECT A2.EMPLD FROM PS_ADDRESSES A2
AND A2.ADDRESS_TYPE = 'HOME')
 Select employees who belong to department 15000 since 2009-01-01

SELECT A.EMPLD, A.EMPL_RCD, A.EFFDT, A.EFFSEQ
FROM PS_JOB A
AND A1.EFFDT <=’2009-01-01’)
AND A.DEPTID =’15000’

Select employees whose date of birth is less than 1980 Jan 1 st
SELECT * FROM PS_PERSON WHERE BIRTHDATE < '1980-01-01'
 Select employees who are hired in this year 2009
SELECT EMPLID, HIRE_DT FROM PS_JOB A
AND A.HIRE_DT BETWEEN '2009-01-01' AND '2009-12-31'
 Select employees who do not have personal phone defined

AND NOT EXISTS (SELECT ‘X’ FROM PS_PERSONAL_PHONE B
WHERE B.EMPLID = A.EMPLID)
 Select employees who are born in USA and working in IND


AND A.REG_REGION =’IND’
AND EXISTS (SELECT ‘X’ FROM PS_PERSON B
WHERE B.EMPLID = A.EMPLID
AND B.BIRTH_COUNTRY =’USA’)
 Select employees who are born in IND and working in USA

AND A.REG_REGION =’USA’
AND EXISTS (SELECT ‘X’ FROM PS_PERSON B
WHERE B.EMPLID = A.EMPLID
AND B.BIRTH_COUNTRY =’IND’)
 Select employees who are having multiple jobs

SELECT A.EMPLID, COUTN(A.EMPL_RCD)
FROM PS_JOB A
GROUP BY A.EMPL_RCD
HAVING COUNT(A.EMPL_RCD) > 1
 Select employees who are inactive as on 2009-01-01  HR_STATUS = ‘I’

AND A.HR_STATUS =’I’
 Select employees who are on leave as on 2009-01-01  EMPL_STATUS = ‘L’


AND A.EMPL_STATUS =’L’
9. Activity 2:
 Select employee data whose company is 13000
SELECT EMPLID, EMPL_RCD, EFFDT, EFFSEQ
FROM PS_JOB WHERE COMPANY =’13000’;
 Select employee data who are hired on 2009 January 1 st.

SELECT EMPLID, EMPL_RCD, EFFDT, EFFSEQ
FROM PS_JOB WHERE EFFDT = ‘2009-01-01’ AND ACTION =’HIR’
 Select employees who are in company KCY as on effective date 2009-12-31

SELECT A.EMPLID, A.EMPL_RCD, A.EFFDT, A.EFFSEQ
FROM PS_JOB A
WHERE A.COMPANY = ‘KCY’
WHERE A1.EMPLD = A.EMPLID
AND A1.EFFDT <= ‘2009-12-31’)
WHERE A2.EMPLD = A.EMPLID
AND A2.EFFDT = A.EFFDT)`
 Select employees who are having multiple changes on same day 2010-06-01
SELECT A.EMPLID, A.EMPL_RCD, A.EFFDT, COUNT(A.EFFSEQ)
FROM PS_JOB A
WHERE A.EFFDT = ‘2010-06-01’
GROUP BY A.EMPLID, A.EMPL_RCD, A.EFFDT
HAVING COUNT(A.EFFSEQ) > 1
 Select all the rows of the employee 1234

SELECT * FROM PS_JOB WHERE EMPLID =’1234’
 Select all the employees are paid merit on Dec 1 st 2009

SELECT EMPLID FROM PS_JOB WHERE ACTION =’PAY’ AND ACTION_REASON = ‘MER’
AND EFFDT =’2009-12-01’
 Delete an employee 1234 from the system completely
DELETE FROM PS_JOB WHERE EMPLID =’1234’
DELETE FROM PS_JOB_JR WHERE EMPLID =’1234’
DELETE FROM PS_JOB_EARNS_DIST WHERE EMPLID =’1234’
DELETE FROM PS_COMEPNSATION WHERE EMPLID =’1234’
This will delete employee information only from Job Data component. However if we want to
delete all referenced tables of the employee then we need to run the process called Employee
Purge in the workforce administration. This process will delete employee information from all
possible tables
 Delete employee record 1 for the employee 1235

DELETE FROM PS_JOB WHERE EMPLID =’1235’ AND EMPL_RCD = 1
DELETE FROM PS_JOB_JR WHERE EMPLID =’1235’ AND EMPL_RCD = 1
DELETE FROM PS_JOB_EARNS_DIST WHERE EMPLID =’1235’ AND EMPL_RCD = 1
DELETE FROM PS_COMEPNSATION WHERE EMPLID =’1235’ AND EMPL_RCD = 1
This will delete employee’s particular EMPL_RCD information only from Job Data component.
However if we want to delete all referenced tables of the employee’s RCD# then we need to run
the process called Employee job Purge in the workforce administration. This process will delete
employee’s RCD# information from all possible tables
 Delete employee 1235’s latest row

DELETE FROM PS_JOB WHERE EMPLID = ‘1235’
AND EFFDT = (SELECT MAX(A.EFFDT) FROM PS_JOB A
WHERE A.EMPLID = PS_JOB.EMPLID
AND A.EMPL_RCD = PS_JOB.EMPL_RCD
AND A.EFFDT <= GETDATE())
AND EFFSEQ= (SELECT MAX(B.EFFSEQ) FROM PS_JOB B
WHERE B.EMPLID= PS_JOB.EMPLID
AND B.EMPL_RCD= PS_JOB.EMPL_RCD
AND B.EFFDT = PS_JOB.EFFDT)
 Update employee 1235 salary to 250000

UPDATE PS_COMPENSATION
SET COMPRATE =’250000’
WHERE EMPLID =’1235’
AND EFFDT = (SELECT MAX(A.EFFDT) FROM PS_COMPENSATION A
WHERE A.EMPLID = PS_ COMPENSATION.EMPLID
AND A.EMPL_RCD = PS_ COMPENSATION.EMPL_RCD
AND A.EFFDT <= GETDATE())
AND EFFSEQ= (SELECT MAX(B.EFFSEQ) FROM PS_ COMPENSATION B
WHERE B.EMPLID= PS_COMPENSATION.EMPLID
AND B.EMPL_RCD= PS_ COMPENSATION.EMPL_RCD
AND B.EFFDT = PS_ COMPENSATION.EFFDT)
 Update employee 1235 action/reason to LOA/STD instead of LOA/FML
UPDATE PS_JOB
SET ACTION =’STD’
WHERE EMPLID =’1235’ AND ACTION =’LOA’ AND ACTION_REASON =’FML’

Introduction to PeopleSoft Fundamentals

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Introduction to PeopleSoft Fundamentals

Diunggah oleh

Hak Cipta:

Format Tersedia

PeopleSoft Fundamentals Introduction

High-level PeopleSoft Pure Internet Architecture relationships

Sample Web Reference URL: http://peoplebooks.cognizant.com/

There are two Broad categories of PeopleBooks:

1. Select all employees of company 001?

How to start Application Server?

Follow below sequence of instructions to start an application server.

How to Stop Application Server and Clear Cache?

Organizational relationships fall into one of the following categories:

 Stock - non-HR administered employees.

Action Date Employment Instance Contingent Worker Instance POI Instance

March 1, 1997 POI instance created.

April 7, 1997 POI instance job

April 7, 1997 Employment instance created

March 1, 2001 Promoted.

Action Date Employment Instance Contingent Worker Instance

May 1, 1996 Employment instance created. Job record identified by:

May 1, 1998 Substantive job suspended.

November 1, Temporary assignment completed.

November 1, Substantive job resumed.

Action Date Employment Instance Contingent Worker Instance

1999 identified by:

Jan Smith’s job records from May 1, 1996 to February 1, 1999

EMPL_RCD  Key: Employee Record tracks the multiple jobs of an

EFFSEQ  Key: Effective Sequence helps in storing changes on same

ACTION: Action stores change happened to employee’s job. Hire,

ACTION_REASON: Action Reason stores reason behind an action. It can

STEID_ LOCATION /LOCATION: It refers to the location code where the

SETID_DEPT/DEPTID: The department to which employee works for.

BUSINESS_UNIT: Business Unit is the logical separation of enterprise in

REG_REGION: Regulatory Region is the geographical unit which is bound

POSITION_NBR: The position which the employee holds in the

SETID_JOBCODE/ JOBCODE: The jobcode is a unique code that

Entry dates that are stored in JOB:

PER_ORG: There exist three types of relationships for persons with

HR_STATUS: This represents if the person is still active in the organization

EMPL_STATUS: This presents detailed status of the person. Is the person

EMPL_CLASS: This shows whether employee is Local, International

EMPL_TYPE: Employee type determines whether employee is Salaried,

OFFICER_CD: This determines the position of the officer like Director,

blank for normal employees.

REG_TEMP: Is the employee Regular worker or Temporary worker.

FULL_PART_TIME: Used to determine whether Full time worker or Part

SETID_SALARY/SAL_ADMIN_PLAN: Salary administration plan to which

PAYGROUP: A pay group is a logical grouping of qualifying individuals for

HOLIDAY_SCHEDULE: Used to determine the holiday schedule of the

BAS_GRUOP_ID: Benefits Administration System Group ID is used to

ELIG_CONFIG1, ELIG_CONFIG2, …, ELIG_CONFIG9: These fields are

PS_JOB_JR This contains same keys as that of JOB

COMPRATE: Compensation amount agreed by the worker

Tabular Related Information:

This is the parent table of the personal information. It stores information

PS_NAMES EMPLID  Key

o Purpose of tables in a database:

EMPLID COMPANY COMPANY_NAME COM_HQ_ADDR LOCATION

What is relevant population?

Employee: EMPLID COMPANY LOCATION

What is a record? Collection of fields is a record. It is a logical grouping of data.

12340200901010HIRNPSGBI  Data unorganized

1234 0 2009-01-01 0 HIR NPS GBI  Data organized

Murty 0 2009-01-01 0 HIR NPS GBI  Data organized

EMPLID is a key to identify above rows