Oracle ps person_model rev 08242005

Understanding the Enterprise
HCM Person Model in Release 8.9

An Oracle Red Paper
[August] [2005]

Understanding the Enterprise HCM Person Model in Release 8.9

Introduction..................................................................................................................................................................... 1
What is the Person Model?............................................................................................................................................ 1
Terminology..................................................................................................................................................................... 1
Models .............................................................................................................................................................................. 5
Person Object Model ERD– Core Entities ........................................................................................................... 5
Person Object Model ERD –Country and Product Extensions....................................................................... 10
Organizational Relationships ................................................................................................................................. 13
Persons of Interest............................................................................................................................................. 14
Organizational Relationship Model ERD – Overview....................................................................................... 17
Organizational Relationship Model ERD – Relationships with Assignments ................................................ 19
Understanding the design of PER_ORG_INST ................................................................................................ 21
Organizational Relationship Model ERD – Relationships with Assignments (with Extensions) ................ 24
Organizational Relationship Model ERD – Relationships without Assignments .......................................... 27
Online Functionality..................................................................................................................................................... 29
Creating a Person..................................................................................................................................................... 29
Person Checklist ...................................................................................................................................................... 34
Creating Organizational Relationships ................................................................................................................. 36
Creating Worker Organizational Relationships and Instances .......................................................................... 39
Additional Assignment or New Instance? ........................................................................................................... 42
Instance Dates versus Assignment Dates ............................................................................................................ 44
Promoting an Assignment to an Instance............................................................................................................ 51
Reviewing a Person’s Organizational Relationships ........................................................................................... 52
Setup Tables................................................................................................................................................................... 55
Person of Interest Type Setup Table .................................................................................................................... 55
Person Object Installation Setup Table................................................................................................................ 58
JOB Actions ............................................................................................................................................................. 58
PERSONAL_DATA Snapshot Reporting Table ............................................................................................... 65
POI Organization Summary Views....................................................................................................................... 69
Appendicies ................................................................................................................................................................... 73
Appendix A: Adding a New POI Type ....................................................................................................... 73
Appendix B: Job Action Table Values ........................................................................................................ 75
Appendix C: New Assignment Decision Matrix.......................................................................................... 1

August 2005 Understanding the Enterprise HCM Person Model in Release 8.9 Page 1

INTRODUCTION
Oracle’s PeopleSoft Enterprise HCM 8.9 provides enhancements enabling you to handle different types
of people in your system. You are no longer limited to tracking just your workforce. This document will
explain these improvements and discuss how you can use the new model. Upgrade specific information is
not included here.

Note. For information about how the Person Model impacts upgrades, please refer to the
Understanding the Person Model Changes appendix in the upgrade documentation.

The major enhancements delivered by the Person Model for Enterprise HCM 8.9 are:
• The ability to track a person without having to create a JOB record.
• The ability to use the same ID for a person across multiple relationships to the organization. For
example, you can use the ID of a former employee who joins the organization as a contingent
worker.
• Improved handling of Global Assignments
• Improved handling of Additional Assignments.
• The separation of the creation of a person in the system from the creation of that person’s
relationships with the organization.
• Real-time updates of the snapshot reporting table PERSONAL_DATA.
• Capture and use of people’s name in a user-friendly manner.
• Greater tracking capability for your workforce

WHAT IS THE PERSON MODEL?
The Person Model is a term used to describe the information captured about a person and how the
person is related to the organization. This model includes the core tables that are used by all products that
are directly related to a person and their organizational relationships in the Enterprise HCM system. This
document describes these tables, the relationships, and what this functionally enables you to do.

TERMINOLOGY

Term Definition
Person Any human being with a relationship to the organization that you
wish to track in your system.
Field: EMPLID
Organizational Relationship How a person is related to the organization as represented in the
database. There are three major categories of people that HCM
Field: PER_ORG
tracks information on:


Term Definition
• Employee
• Contingent Worker
• Person of Interest
A person can have one or more of these relationships at any one
time, including multiple occurrences of the same relationship.
Each distinct relationship that includes a Job Data record is
uniquely identified by an EMPL_RCD.
Note. The relationships of people of interest do not always include
a Job Data record.
Employee (EMP) (Plural: Employees / Employed Workforce)
Field: PER_ORG The relationship of a person who is hired to provide services to a
company on a regular basis in exchange for compensation and
who does not provide these services as part of an independent
business.
An employee can work under a contract.
The exact definition of what defines an employee is left to the
customer since each country has different rules. You will want to
make the determination based on your regulatory requirements.
Each employee relationship must have a distinct EMPL_RCD.
Contingent Worker (CWR) (Plural: Contingent Workers / Contingent Workforce)
Field: PER_ORG The relationship of a person who provides services to another
entity under terms specified in a contract on a non-permanent
basis. Contingent workersinclude independent contractors,
temporary workers, and leased workers.
The exact definition of what defines a contingent worker is left to
the customer since each country has different rules. You will want
to make the determination based on your regulatory requirements.
Each Contingent Worker’s relationship must have a distinct
EMPL_RCD.
Person of Interest (POI) A person who does not have aan employment or a contingent
worker relationship but who is still of interest to the organization.
Field: PER_ORG
HRMS has the need to track information on non-workforce
people in many areas such as Cobra Participants, Pension Payees,
GP Dependents, External Students and Instructors, and so on.
Some POI relationships have job data records that are identified
with a distinct EMPL_RCD.
Others (the ones that do not need JOB information) areidentified


Term Definition
by the POI_TYPE.
Person of Interest Type POI_TYPE
Field: POI_TYPE This field identifies the different types of Persons of Interest that
you need to track. PeopleSoft supplies many defined POI types to
which you can add others.
Some POI Types will require JOB information and others will not.
This is defined as an attribute of the POI_TYPE.
Workforce The combination of your employees and contingent workers is
collectively called your workforce (singularly, they are known as
Field: PER_ORG (values EMP,
workers).
CWR)
Organizational Instance An occurrence of an organizational relationship.
Also known as Controlling Also referred to as an Employment Instance, a Contingent
Instance Workforce Instance, or a POI Instance.
Organizational instances can be limited to one assignment
(EMPL_RCD) or include multiple assignments, depending on
Field: ORG_INSTANCE_ERN
your needs.
When an organizational instance includes more than one
assignment, one of those assignments is identified as the
controlling instance. This EMPLID/EMPL_RCD combination
stores the HIRE_DT, general SERVICE_DT, and the
TERMINATION_DT.
For example, a person can have a single Employment Instance
with a company, but as part of that employment instance, they
have three separate assignments, each identified by different
EMPL_RCD numbers. One of these EMPL_RCDs is identified as
the controlling instance containing the overall dates. The others
refer only to the particular assignment.
Assignment A unique numeric identifier for each relationship that a person has
that requires JOB information. The value of the EMPL_RCD is
Field: EMPL_RCD
not used for anything other than to identify a separate relationship;
it does not rank or otherwise give precedence to one assignment
over another
Additional Assignment An concurrent assignment in addition to, and under an existing
assignment
Also referred to as Multiple Assignments.
Identified by the EMPL_RCD
and the Some organizations allow their workforce to have multiple,
ORG_INSTANCE_ERN concurrent assignments. Each of these assignments needs to be
combination. tracked under a distinct EMPL_RCD. In cases where the customer


Term Definition
does not want to treat these additional assignments as a new
employment relationship (with a Hire action), they can be tied to a
controlling instance, the first assignment the person had
(containing the Hire Date). Additional assignments are treated
specially in certain situations.
Multiple Instances An concurrent assignment in addition to an existing assignment
EMPL_RCD will always equal Some organizations allow their workforce to have multiple,
the ORG_INSTANCE_ERN. concurrent assignments and do wish to track each as a separate
assignment with an action of hire. In this case, create each
assignment as a separate instance (either of Employment or
Contingent Workforce). The multiple instances are not related in
any way to the others instances this person has.


MODELS

Person Object Model ERD– Core Entities
This diagram shows the core records that store the data of a person and his organizational relationships:

Figure 1: Person Object Model – Core Entities

The solid red relationship lines represent required data. A Person is required to have at least one of the
following records:
• PERSON
• NAMES
• PERS_DATA_EFFDT (person history)
• A record for at least one organizational relationship.
The sub-type of the organizational relationship is determined by whether an assignment (JOB) record
is needed or not:
• If a JOB record is needed, then an assignment record is (PER_ORG_ASGN) used.
• If not, a non assignment person type record (PER_POI_TYPE) is created.
A person can have multiple organizational relationships. Organization relationships will be discussed
in detail later.


Not all of the attributes of the entities are required. For example, the only field in the PERSON record
that requires data is EMPLID and only EMPLID and EFFDT are required in the PERS_DATA_EFFDT
record.
When you first create a person in the system you need to enter:
• An EMPLID.
• A primary name.
• The date that the person’s record is available in the system (the PERS_DATA_EFFDT.EFFDT)
which will default to the current date.
• An indication of the organizational relationship you will be creating.
It is important to understand that the PERS_DATA_EFFDT.EFFDT value is not the date of hire,which
may be in the future. This date represents the earliest date upon which that the person is entered in the
system. Therefore, this date cannot be future dated. The hire date can still be future dated as this date is
related to a specific organizational relationship.
There is no attribute that identifies the status of a person in the system at this level. However, you can
track the status of each organizational relationship. One person might have an active employment
relationship and an inactive contingent worker relationship. Another person might have one active
employment relationship and one active contingent worker relationship (this is not a common situation,
but is allowed). A third person might have two active employment relationships.

Core Person Tables Detail
Record Name Category Description
PERSON Core Person
Required Contains the ID and a person’s static data (such as
birthdate and birthplace).
Every person you enter will have one record in
PERSON.
PERS_DATA_EFFDT Core Personal History
Required Contains a person’s core personal data that can
change over time and on which we want to keep a
history of these changes.
There will be at least one record in
PERS_DATA_EFFDT for every person.


NAMES Core Person Names.
Required Contains a person’s name data. You can capture
multiple types of names (NAME_TYPE) and maintain
history for each name type.
Each person must have at least one row for the primary
name type. The system uses the primary name
throughout the database. The other name types are for
informational use and you can add additional name
types.
ADDRESSES Core Person Addresses.
Not Required Contains a person’s address data . You can enter data
for multiple address types (ADDRESS_TYPE) and
track them historically. Address types include Home,
Mailing, Business, and Check. You can add additional
address types.
Address information is not required except if the
person has an employee instance and you use
PeopleSoft Enterprise Payroll for North America.
PERSONAL_PHONE Core Person Phone Numbers.
Not Required Contains a person’s telephone data. You can enter data
for multiple phone types (PHONE_TYPE) and flag
one of them as the primary phone number to indicate
which phone number should be used in the system
when a type is not specified.
Phone information is not kept historically.
Phone information is not required for a person but if
any is entered, then one (and only one) must be marked
as primary.


EMAIL_ADDRESSES Core Person Email Addresses
Not Required Contains a person’s email address data. You can track
data for multiple email types (EMAIL_TYPE) and flag
one of them as the primary address to indicate which
email address should be used in the system when a type
is not specified
Email address information is not kept historically.
Email address information is not required for a person
but if any are entered, then one (and only one) must be
marked as primary.
These are email address are separate from the email
address captured for a user ID in the PSUSEREMAIL
table. This is because not all people are users and not all
users are people tracked in the system.
PERS_NID Core Person National Identifiers.
Not Required Contains the regulatory identifiers required by
countries, such as Social Security Number (USA) or
Social Insurance Number (Canada).
A person can have multiple NIDs with one marked as
primary.
Organizational One row is required Each person must have at least one organizational
Relationship in either relationship defined. These relationships are defined in
PER_ORG_ASGN one of two tables, depending on whether assignment
or data (JOB) is required:
PER_POI_TYPE
When assignment data is required, the relationship is
defined in PER_ORG_ASGN with the unique
identification of an EMPL_RCD.
An EMPL_RCD is a unique identifier within an
EMPLID for separate assignments. The default starting
number is 0, but that can be changed by the user when
creating an assignment.
When a JOB row is not required, the relationship is
defined in PER_POI_TYPE with the unique
identification of a POI_TYPE.


PER_ORG_ASGN Core Person Organizational Assignment
This contains the unique identification of a person and
an organizational relationship. Each separate
relationship has an identification id (EMPL_RCD field)
and has one, and only one, row in PER_ORG_ASGN.
The primary key for an assignment is the combination
of the EMPLID and EMPL_RCD.
PER_POI_TYPE Core Person Organizational Non-Assignment type.
This record contains a unique identification of a person
and a non-assignment type of relationship to the
organization. The primary key for this record is the
combination of EMPLID and POI_TYPE.
A person may have multiple POI_TYPE relationships.


Person Object Model ERD –Country and Product Extensions
This diagram shows the difference between the entities that are part of the core person model and those
that extend the model for a specific country or product:

Figure 2: Person Object Model –Country and Product Extensions

Extensions are entities that are country or product specific. Keeping them separate from the core entities
enables changes to be made to the extensions without impacting the core records. Changes to the
extensions happen more frequently than do changes to the core (for example, when support for a new
country is added). Another benefit of this componentization of the entities is that customers who do not
need to capture Brazilian specific data or have a legal restriction about tracking religion data do not have
to store any data in these records.
The extensions can have a zero too, zero to many, or zero to many over time type of relationships. Those
relationships tracked over time will have the EFFDT field. Note that the EFFDT in these records is
distinct from the EFFDT in the PERS_DATA_EFFDT. They are not related. This means that there
might be five EFFDT rows in PERS_DATA_EFFDT but only one in PERS_SMOKER.


Person Extension Tables Detail
DIVERSITY Extension Diversity information for Canada, the United Kingdom,
and the Netherlands.
A person has only one DIVERSITY row.
DIVERS_ETHNIC Extension Ethnic diversity information is used by some countries.
The zero to many relationship enables you to track
0 to many
multiple ethnicities for a person. For the US, a primary
ethnicity must be indicated. For Australia, there is an
indicator to capture that the person has refused to
specify their ethnicity.
Used by: Malaysia, Singapore, Australia, New Zealand,
and the United States.
DIVERS_RELIGION Extension Religion information used by some countries. The zero
to many relationship enables you to track multiple
0 to many
religions for a person.
Used by: Malaysia, Singapore, Australia, New Zealand,
and India
PLACE_ORIG_CHE Extension Switzerland specific extension that captures the places
of origin for a person. One place must be specified as
0 to many
the main place of origin.
NATIONALITY_GER Extension German specific extension that captures nationality
information for a person.
0 to many
Multiple nationalities can be entered.
PERSON_BRA Extension Brazilian specific extension for a person that captures
voter, military, RG, and CTSP information.
0 to 1
Only one row can be entered.
PERSON_FRA Extension French extension for a person that captures previous
experience information.
0 to 1
Only one row can be entered.
PERS_SMOKER Extension Benefits extension for a person that captures smoking
history.
Historical
PERS_DATA_BRA Extension Brazilian extension for a person that captures
information such as ethnicity, education level, and
Historical
nationality, and tracks it historically. .
PERS_DATA_MEX Extension Mexican extension for a person that captures


Person Extension Tables Detail
Historical information such as Medic region and the AFORE code
and tracks it historically. .
PERS_DATA_IND Extension Indian extension for a person that captures caste
information and tracks it historically.
Historical
PERS_DATA_DEU Extension German extension for a person that captures military
status information and tracks it historically.
Historical
PERS_DATA_FRA Extension French extension for a person that captures information
such as includes military status, entry date to France,
Historical
and CPAM data and tracks it historically. .
PERS_DATA_JPN Extension Japanese extension for a person that captures honseki
prefecture information and tracks it historically.
Historical
PERS_DATA_USA Extension United States extension for a person that captures
information such as proof of citizenship, military status,
Historical
the Medicare entitlement date, and the proof of work
eligibility and tracks it historically..
PERS_DATA_CHE Extension Swiss extension for a person that captures Guardian
Historical
PERS_DATA_ITA Extension Italian extension for a person that captures military
Historical
PERS_DATA_CAN Extension Canadian extension for a person that captures
information such as health care and bilingualism data
Historical
and tracks it historically.
PERS_DATA_ESP Extension Spanish extension for a person that captures military
and Social Security Affiliation and tracks it historically.
Historical
PERS_DATA_FPS Extension French Public Sector extension for a person that
captures information and tracks it historically.
Historical
PERS_DATA_USF Extension US Federal extension for a person that captures
Historical
This record is only used when the US Federal product is
installed. When it is, this record is required.


Organizational Relationships
A person can be important to an organization for many different reasons at many different times
throughout their lifetime. Each relationship may require different attributes and different processing.
With the Enterprise HCM 8.9 Person Model, you can track the personal information about a person in
one place with no redundant data. The relationships that a person has to the organization is tracked in a
different area of the system. For example, you might have a person who has is now an employee but used
to be a contingent worker. The system tracks this person using one ID, which enables their history as a
contingent worker to exist along with their history as an employee.

While Enterprise HCM 8.9 is primarily a Human Resource based system, we recognize that you may want
to track people that have more than just a worker type of relationship to your organization and you also
need to provide secure access to their data just as you would for a worker. The Enterprise HCM 8.9
Person Model allows you to do this. A single person can have many different types of relationships with
your organization and you can provide security based on these relationships and their attributes.
A person can have one or more of the following three relationships :
• Employee:
The relationship of a person hired to provide services to a company on a regular basis in
exchange for compensation and who does not provide these services as part of an independent
business.
• Contingent Worker:
The relationship of a person who provides services to another entity under terms specified in a
contract on a non-permanent basis.
• Person of Interest:
Any other non-worker relationship that a person can have with your organization. This
relationship has sub-types to allow for different processing within the system. Person of Interest
Types (POI Type) are also defined as either requiring a JOB record or not (known as POIs with
jobs and POIs without jobs). Those that need a JOB record are identified by an EMPL_RCD.

The employee and contingent worker relationships represent your workforce and are the main focus of
the business processes in Enterprise HCM. Most of the processes that are designed for employees are also
available for contingent workers with the following exceptions:
• Payroll for North America
• Plan Salary
• Plan Careers and Successions
• Variable Compensation.
People of interest are not generally included in HCM business processes, except those that are designed to
manage this specific relationship (such as COBRA participants or Pension payees).


Persons of Interest

HCM 8.9 delivers pre-defined person of interest types but you can easily add their own.
The following table lists the POI types delivered with the system. You can create additional types for
POIs without jobs at any time using the Person of Interest Types component (Set Up HRMS, Foundation
Tables, Organization, Person of Interest Types).

Person of Interest Types
JOB
POI_TYPE Description Reqd Comment
00000 Unknown N This POI type is used when a user creates a
person is created but does not create an
organizational relationship.
Having this POI_TYPE will ensure that some
user will be able to access these people. Once a
known organizational relationship is created the
system deletes the Unknown one.
00001 COBRA Qualified Beneficiary Y Used by PeopleSoft Benefits Administration for
COBRA beneficiaries. These relationships can
only be created on the components on the
COBRA menu.
00002 Pension Payee Y Used by PeopleSoft Pension Administration.
This relationship can only be created on the
components on the Pension Administration
menu.
00003 Stock - Board Member Y Used by PeopleSoft Stock Administration.
00004 Stock - Non-HR Employee Y Used by PeopleSoft Stock Administration.
00005 Global Payroll Payee Y Used by the PeopleSoft Global Payroll
applications.
00006 Student Refund Y Used by PeopleSoft Campus Solutions
applications.
This POI_TYPE is created in the JOB table to
process students who need to receive a refund
payment using PeopleSoft Payroll for North
America. Payroll for North America requires that
people have a JOB record in order to process
their check.
00007 External Trainee N Used by PeopleSoft Human Resources
Administer Training . This relationship can be
created in components on the Administer
Training menu, the Administer Workforce menu,
and also on Recruiting Solutions menus for
people who need training prior to being hired.
00008 External Instructor N Used by PeopleSoft Human Resources
Administer Training.
While some external instructors are entered into
the system as contingent workers and have a JOB
record, some external instructors do not need a
JOB record. This POI_TYPE relationship is used
for external instructors who are not contingent
workers.


Person of Interest Types
JOB
POI_TYPE Description Reqd Comment
00009 Campus Solution Person N Used by PeopleSoft Campus Solutions
applications. This relationship is created and
maintained on the components on the Campus
Solutions menus.
00010 Other N Any other person that you need to track within
HCM.

The following table lists the self-service components that a person, regardless of relationship, can access
and update if given a user ID and access to the Self Service components:

Self Service Transactions in HRMS accessible by any Person in the PERSON table
Component Description Component Name
Home and Mailing Address HR_HOME_MAILING
Phone Numbers HR_PERSONAL_PHONE
Email Addresses HR_EMAIL_ADDRESSES
Emergency Contacts HR_EMERGENCY_CNTCT
Marital Status HR_EE_MAR_STATUS
Name Change HR_EE_NAME
Professional Training HR_PROF_TRAINING
Education HR_EDUCATION
Honors and Awards HR_HONORS_AWARDS
Languages HR_LANGUAGES
Licenses and Certificates HR_LIC_CERT
Memberships HR_MEMBERSHIPS

Persons of Interest are not available in all components of the system (since HRMS is primarly concerned
with workers). The following table lists the components where the data on the POIs can be accessed in
addition to the employees and contingent workers. Normal row level security is also applied.

Administrator components in HRMS accessible for any Person in PS_PERSON
Modify a Person PERSONAL_DATA
Disabilities DISABILITY
Prior Work Experience PRIOR_WORK_EXPER
Credit Cards CC_CARD_DATA
Emergency Contacts EMERGENCY_CONTACT
Drivers License DRIVERS_LICENSE

Identification (Visa, Passport, Citizenship, Photo) IDENTIFICATION_DATA
Company Property COMPANY_PROPERTY
Volunteer Info EMPL_VOLUNTEER
General Comments GENL_COMMENTS
Bank Accounts PYE_BANKACCT
Training TRN_STUDNT_CRS_DT2


Administrator components in HRMS accessible for any Person in PS_PERSON
Training Summary TRN_STUDNT_CRS_SU3
Education EDUCATION
Person Checklist PERSON_CHECKLIST
Accomplishments
Languages LANGUAGES
Licenses and Certificates LICENSES_CERTIFS
Memberships MEMBERSHIPS
Test Results TEST_RESULTS_PANEL
Honors and Awards HONORS_AWARDS
Significant Special Projects SPECIAL_PROJECTS

Competencies COMPETENCIES
Health and Safety
Audiometric Exam HS_EXAM_AUDIO
Eye Exam HS_EXAM_EYE
Physical Exam HS_EXAM_PHYSICAL
Respiratory Exam HS_EXAM_RESPIRE
Drug Test GVT_DRUG_TEST
Health Card GVT_HEALTH_CARD


Organizational Relationship Model ERD – Overview
The organizational relationship defines the relationship or relationships that a person has with your
organization. These may be worker or non-worker relationships and a single person can have many
different relationships at the same time or over a lifetime.
Each person must have at least one defined organizational relationship. These relationships are defined in
one of two tables depending on whether assignment data (JOB) is required. When assignment data is
required, the relationship is defined in PER_ORG_ASGN with the unique identification of an
EMPL_RCD.
An EMPL_RCD is a unique identifier for separate assignments within an EMPLID. The value of the
EMPL_RCD itself does not indicate anything or carry any processing. The default starting number is 0,
but that can be users can change this creating an assignment.
When an assignment is not required, the relationship is defined in PER_POI_TYPE with the unique
identification of a POI_TYPE.
There are some non-worker relationships that do require assignment information. These are the
relationships that are supported by various HCM products such as PeopleSoft Benefits Administration
(Cobra Participants) and Pension Administration (Pension Payees). These relationships have special
processing that requires data that is associated with an assignment. Therefore, these relationships will have
an assignment (and EMPL_RCD), but are still non-workers. We will cover each type of relationship
below.


Figure 3: Person Model –Organizational Relationship Summary


Organizational Relationship Model ERD – Relationships with Assignments
This model illustrates the core records that the system uses to define any organizational relationship that
requires an assignment.

Figure 4: Person Object Model – Organizational Relationship with Assignments

Before we discuss the individual records, we need to understand the implied and enforced relationships
between PER_ORG_INST and PER_ORG_ASGN.
In the figure above, there is a foreign key relationship between the PER_ORG_INST
ORG_INSTANCE_ERN field and the PER_ORG_ASGN ORG_INSTANCE_ERN field. This is
actually an implied parent/child relationship between these records that is enforced by business logic.
• Each controlling instance (PER_ORG_INST) controls one or more assignments
(PER_ORG_ASGN).
• Each assignment (PER_ORG_ASGN) has one, and only one, controlling instance
(PER_ORG_INST).

A PER_ORG_INST is a single instance of an organizational relationship (with a job), as defined by the
customer. The instance enables us to distinguish between assignments that represent a true new-hire type


relationship as opposed to just an additional assignment. The key distinguishing factor is whether the
person’s assignment should be treated as a new-hire or not.
For example, Kelly Jones is hired into the organization as an employee on January 14, 2003 and her
assignment is as a clerk in department A. On July 1, 2000, she takes on another job in department B.
If the second job is tied to Kelly’s first job and you do not want it identified as a hire, then you create the
second job as an additional assignment to the first job, making the first job the controlling instance.
When you report on the new hires in your organization, the system will not include the second job .
Likewise, when you terminate the position, the system does not count it as a termination since Kelly is
still employed with the organization through the controlling instance. All of Kelly’s service dates are
determined by the controlling instance.

To process the two assignments as completely separate relationships with the organization (each having
its own set of hire and service dates), then you create them as separate organizational instances.

There are several reasons for creating the link between an additional assignment and an instance;
• You can see the person’s date of hire even when looking at the additional assignment data.
• The system will automatically terminate all of a person’s additional assignments when you terminate
the controlling instance.
• Using data permission security, you can give a user access to the controlling instance if they have
data permission access to one of its additional assignments (or the other way around).
• With Global Assignments, you need to indicate that a Host assignment is controlled by a specific
Home assignment.

Whether you use separate instances or additional assignments is up to you to determine based on your
workforce policies. Most processing within HRMS does not distinguish between controlling instances
and additional assignments. The business processes where this is distinction is important are:
• Regulatory reporting such as new hire and termination reporting.
• Global Assignment host tracking .
• Temporary assignment processes (where an instance is put on a temporary suspension during
which another assignment is performed).
• Japanese Kenmu additional assignments
• Termination of a controlling instance

For Customers who are upgrading from a previous release:


The controlling instance is analogous to creating an additional job with the Action of HIR (Hire).
The additional assignment is analogous to creating an additional job with the Action of ADL –
additional assignment. The big differences are that now we require that you indicate what job will
be the controlling instance for an additional job and we will automatically terminate all additional
instances for you. The upgrade process will identify these relationships for you, but you may
need to make some corrections to orphaned assignments. Please refer to the Upgrade Appendix
instructions.

Understanding the design of PER_ORG_INST
The reason we did not make PER_ORG_INST a physical parent of PER_ORG_ASGN was to limit the
huge impact that this would have had both within HRMS and when integrating to other systems. Using
the two keys EMPLID and EMPL_RCD to uniquely identify a job has been in place in PeopleSoft
products for many releases. Adding a new key (ORG_INSTANCE_ERN) would require an enormous
amount of changes within HRMS and within any system that is integrated with it.
Because most products that use the EMPLID/EMPL_RCD combination have no need to know or
worry about the difference between an instance and an assignment, making PER_ORG_INST a parent
of PER_ORG_ASGN would have caused enormous changes without much benefit. It is only the
Human Resource product (and only in some very specific situations) that needs to know when a
particular EMPL_RCD is an instance or an additional assignment. For this reason, PeopleSoft decided to
put the onus on those specific areas of the Human Resource product to deal with the difference instead
of all other products.
Users who can create organizational relationships do need to understand the difference (or the
implementation team needs to have made a decision on which method to use, if only one is to be used)
because it impacts which component users use to create a new assignment.


The logical model is this:

Figure 5: Logical relationship between PER_ORG_INST and PER_ORG_ASGN

There are three core JOB relationship records. These are described in the table below. Again, most
processes only use PER_ORG_ASGN and JOB. Only those few processes that need to identify when
something is a controlling instance versus and additional assignment will need to use PER_ORG_INST.

Core JOB Relationship tables
PER_ORG_INST Core Person Organizational Instance
A single instance of an organizational relationship as
defined by the customer. This organizational instance
may include more than one assignment
(PER_ORG_ASGN.EMPL_RCD).
Each controlling instance (PER_ORG_INST) controls
one or more assignments (PER_ORG_ASGN).
Each assignment (PER_ORG_ASGN) has one, and
only one, controlling instance (PER_ORG_INST).
This record provides a unique identification of a person
and an organizational relationship. Each separate
relationship has a unique identification ID
(EMPL_RCD field) and has, one and only one, row in


Core JOB Relationship tables
PER_ORG_ASGN.
JOB Core Person Organizational Assignment History.
This record provides an historical record of information
directly related to one assignment (EMPLID /
EMPL_RCD). Each PER_ORG_ASGN parent has at
least one JOB child row. Multiple rows can be entered
for the same day.
PER_POI_TYPE Core Person Organizational Non-Assignment Relationship.
This record defines a person’s organizational
relationships that do not require an assignment (i.e. JOB
data). Each row is uniquely identified by the EMPLID
and the POI_TYPE (the person of interest type). Each
separate (non-JOB) POI relationship has a single row
in PER_POI_TYPE.
PER_POI_SCR_DT Core Person Organizational POI Security
PER_POI_SCRTY This record provides an historical record of information
directly related to one Person of Interest relationship
without a job. Each PER_POI_TYPE parent has at
least one PER_POI_SCR_DT child row, which can
have one or more PER_POI_SCRTY rows.


Organizational Relationship Model ERD – Relationships with Assignments (with
Extensions)
This section covers the entire JOB core model with some extensions.

Figure 6: Person Model - Organizational Relationships with Assignments – with Extensions

Assignment Tables – Core and Extension
PER_ORG_INST Core Person Organizational Instance
Required A single instance of an organizational relationship as
defined by the customer.
Required This record provides a unique identification of a person and
an organizational assignment.
JOB Core Person Organizational Assignment History
Required This record provides an historical record of information
EMPL_RCD).


JOB_JR Core Extension of JOB
Required This record has a mandatory one to one relationship with
JOB. It is a true sibling of the JOB record and was originally
created to allow more than 250 fields to be associated with a
JOB.
JOB_USF Product Extension of Job for US Federal Data.
Extension This record has a mandatory one to one relationship with
Required if JOB but only if US Federal is installed. If it isn’t installed,
US Federal is then no data is loaded into this record. These fields used to
installed. be directly on the JOB record but have now been moved to
this extension record instead.
COMPENSATION Core Person Job Compensation and History
Not Required This record contains the components of a person’s
compensation-related data. It is a child of JOB, so it also
provides a history as well as a moment in time snapshot of
compensation data. Each JOB row can have zero, one, or
more COMPENSATION rows.
HR_EE_SNR_DTS Core Person Job Seniority Dates and History
Not Required This record contains Labor Agreement and Seniority date
information for a JOB row. Each JOB row can have zero,
one, or more HR_EE_SNR_DTS rows.
JOB_IND Country Person Job Extension for India
Extension Contains specific data for India. This is an extension of JOB
Not Required with a one-to-one relationship. If no data is needed for
India for a specific assignment, then this record will not
have a row.
Data includes Union Membership Status and Category.
JOB_AUS Country Person Job Extension for Australia and Australia
Extension Higher Education
Not Required Contains specific data for Australia such as Salary packaging
indication, Casual Job indicator, and Payroll Tax State. This
is an extension of JOB with a one-to-one relationship. If no
data is needed for Australia for a specific assignment, then
this record will not have a row.
PER_ORG_ASG_BEL Country Person Org Assignment Extension for Belgium
Extension Contains specific non-historical official language data for
Not Required Belgium. This is an extension of the PER_ORG_ASGN
record and has a one-to-one relationship (when data is
entered).
PER_ORG_ASG_BRA Country Person Org Assignment Extension for Brazil
Extension Contains specific non-historical INSS data for Brazil. This is
Not Required an extension of the PER_ORG_ASGN record and has a
one-to-one relationship (when data is entered).
PER_ORG_ASG_HP Industry Person Org Assignment Extension for the Education
Extension and Government industry
Not Required Contains specific non-historical tenure data for E&G. This
is an extension of the PER_ORG_ASGN record and has a
one-to-one relationship (when data is entered).
PER_ORG_ASG_JPN Country Person Org Assignment Extension for Japan
Extension Contains specific non-historical education level data for
Not Required Japan. This is an extension of the PER_ORG_ASGN
record and has a one-to-one relationship (when data is


entered).
PER_ORG_ASG_NLD Country Person Org Assignment Extension for the Netherlands
Extension Contains specific non-historical owner relationship data for
Not Required the Netherlands. This is an extension of the
PER_ORG_ASGN record and has a one-to-one
relationship (when data is entered).
PER_ORG_ASG_FA Country Person Org Assignment Extension for the Malaysia
Extension and Singapore
Not Required Contains specific non-historical festive advancement data.
This is an extension of the PER_ORG_ASGN record and
has a one-to-one relationship (when data is entered).


Organizational Relationship Model ERD – Relationships without Assignments

This model illustrates the core records that are used to define an organizational relationship that does not
require a JOB record.

Figure 7: Person Object Model – Organizational Relationship without Assignments

Person Relationships without Assignments Tables
PER_POI_TYPE Core Person Organizational Non-Assignment Relationship
This record defines the organizational relationships
that a person can have that do not require an
assignment (i.e. JOB data). Each row is uniquely
identified by the EMPLID and the POI_TYPE (the


Person Relationships without Assignments Tables
person of interest type). Each separate POI without
job relationship has a single row in PER_POI_TYPE.
PER_POI_SCR_DT Core Person Organizational Non-Assignment Relationship
Required History
This record provides an historical record of
information directly related to one Person of Interest
without job relationship. Each PER_POI_TYPE
parent will have at least one PER_POI_SCR_DT
child row.
PER_POI_SCRTY Core Row Level Security attributes
Required Contains the field and values of data that can be used
to define data permission security access for these
relationships.
Transaction Record Core and The special Transactional history for this relationship
Extensions is captured in separate records based on the
POI_TYPE.
PER_POI_TRANS Default Default Transactional history record available for
Transaction multiple POI_TYPES. This record is used when there
and History isn’t a product-specific transaction table. It contains
basic historical information such as EFF_STATUS
with an Effective Date and a comment area. This
record can be easily used for customer-created
POI_TYPES without any customization.
CAREER_SDNT Product Campus Solutions transaction record for Campus
specific Solutions persons
transaction
TRN_INSTRCT_TBL Product HR Training – Instructor Table – used for the
specific transaction history of External Trainer POI_TYPES
transaction (as well as providing additional information on
and history Employees or Contingent Workers who are Trainers).

The data permission security access for POIs without jobs is based on the data found in
PER_POI_SCRTY. This record has been created with generic field names for the security fields so that
the customer can decide what transaction data they want to use (and capture) for these relationships.
HCM delivers a few security fields already defined, but the customer can create new ones using the Core
Row Level Security components without having to do customizations


ONLINE FUNCTIONALITY

Creating a Person
There are several places on the Enterprise HCM portal menus where you can create a new person. On
each component users can search first to see if the person they want to add already exists in the database.
Encourage users to check for existing person records before adding new ones to prevent creating multiple
IDs for the same person.The system issues a warning if the person may already be in the database, but the
user can continue with the new ID. It is possible to create multiple IDs for a person if it is necessary due
to integration or functional needs.

Note. Please refer to the PeopleSoft Enterprise HRMS 8.9 Application Fundamentals PeopleBook,
“Setting up and Using Search Match” for more information.

Components on some menus allow users to create only one specific organizational relationship for a
person. For example, on the Add a Person component on the Enterprise Learning menu, you can only
create a POI without job with a POI type of either External Trainees or External Instructors. However,
on the component on the Administer Workforce menu, there are more POI types available. Some
components, such as PERSONAL_DATA, update the core person and relationship records directly while
others use a service or component interface to update the core tables at save time. This ensures that all
updates to the core tables apply the same business rules and processing.

Component: PERSONAL_DATA
Navigation: Workforce Administration, Personal Information, Add a Person

When you create a person for the first time using the Add a Person component, the search page looks like
this:

If you use automatic numbering, leave NEW as the Person ID and the system will use the next available
ID when you save the person. Enter a specific new ID to use your own numbering scheme.


When you click on the Add the Person link, the system displays the Add a Person (PERSONAL_DATA)
component. This component contains a person’s basic, personal information on the first three pages:

Biographical Details Page:

The Biographical Details page displays biographical details, such as primary name, date and place of birth,
and national ID.


Contact Information Page

The Contact Information page displays a person’s addresses, phone numbers, and email addresses.


Regional Page

The Regional page contains the country extension information for a person.

Note. The system only displays the countries that you have installed and to which the user has
security access.


Organizational Relationships Page

The fourth page, Organizational Relationships, is only available in the PERSONAL_DATA component
when in add mode. Use this page to create the initial organizational relationship for the person.

Select one of the three types of relationships for this person. Depending on the option you choose, the
system may display additional fields, such as the Person of Interest Type field if you select Person of
Interest. If you select Employee or Contingent Worker, the system will enable you to enter the initial
EMPL_RCD. The system enters the 0 (zero) to start with, but you can override this value. This feature is
delivered in the Resolution: 610712 (Bundle 601072).
After you specify the relationship you are adding for the person and click the Add the Relationship
button, the system saves the PERSONAL_DATA component and moves you to the one of the following
components, according to the relationship you choose, upon which you can create the relationship:
• New Employment Instance component (JOB_DATA_EMP), when you add an employee
relationship.
• New Contingent Worker Instance component (JOB_DATA_CWR), when you add a contingent
worker instance.
• New POI Instance component (JOB_DATA_POI), when you add a POI with a job.
• Add a POI Relationship component (PERS_POI_ADD), when you add a POI without a job.

Note. The system determines whether the POI has a job by the POI type
(POI_TYPE_TBL.PNLGRPNAME) you select.

Note. You can determine which POI types should be available on the components that add
people to the system on the Person of Interest Types component. For example, you can limit
the Global Payroll Payee POI type to the component on the Global Payroll menu but make the
External Trainee and External Instructor POI types available on the component on the
Enterprise Learning menu and the component on the Administer Workforce menu. Use the
Person of Interest Type component to create additional POI types as needed.

After you have entered the appropriate relationship data and saved the component, the system returns
you to the the Organizational Relationship page.


If you save the PERSONAL_DATA component before adding a relationship, the system issues a
warning but continues with the save. You can still choose to add a relationship at that time by clicking the
Add a Relationship button on the Organizational Relationships page or by selecting one of the
components from the menus.
HCM data permission uses the data in a person’s organizational relationship transaction record to control
access to the person’s record so every person in the system must have at least one organizational
relationship.
If you save a person without creating a record for the relationship, the system saves the person with a
POI type of Unknown so that you can still make the record available to users with access to people with
the POI type of Unknown using data permission security. The system deletes the Uknown POI
relationship when you create a relationship.

Person Checklist
When you select a person’s relationship on the Organizational Relationships page, you can also select and
create a checklist for them. A checklist is a list of additional components that need to be completed for a
person. When you select a checklist code for a person and create the relationship, the system also creates
a record in the Person Checklist component (PERSON_CHECKLIST on the Workforce Administration,
Personal Information, Organizational Relationships menu).
The system enters a default checklist in the Checklist Code field when you select a relationship. For
example, when you select Employee, the system enters the Add Employment Instance checklist.

Select the Checklist Code when you add an organizational relationship.
Click the Go to Person Checklist link to go to this person’s checklist on the Person Checklist
component.

Person checklists are similar to assignment except that these are keyed by EMPLID only while assignment
checklists are keyed by the EMPLID/EMPL_RCD combination. The assignment checklist component
(EMPLOYEE_CHECLIST) is located on the Workforce Administration, Personal Information,
Organizational Relationships menu. A person can have multiple checklists either at the same time or over
time. Review a person’s checklist(s) in the Person Checklist component. (PERSON_CHECKLIST):


Component: PERSON_CHECKLIST
Navigation: Workforce Administration, Personal Information, Organizational Relationships, Person
Checklist

Person Checklist page

For example, the Add Employment Instance checklist (HCEMP) has three items that contain
components that might be needed for a person with an employee relationship. When you click on this
checklist item, the system opens another window and displays the Add Employment Instance component
(JOB_DATA_EMP). Click the Person Identification checklist item and the system opens a window
displaying the Identification Data component (IDENTIFICATN_DATA).

The Person Checklist functionality gives your organization a way to organize the type of data that is
needed for a particular person or relationship. We deliver several checklists with the system, but you can
easily create your own and use those for defaults on the Organizational Relationships page.

You can define checklists on the Checklist component (CHECKLIST_TABLE, on the Set Up
HRMS:,Common Definitions menu) and associate them with POI types on the Person of Interest Types
component (POI_TYPE_TBL, on the Set Up HRMS, Foundation Tables, Organization menu).

Note. Refer to the PeopleSoft Enterprise Human Resources 8.9 PeopleBook: Administer Workforce,
“Setting up the Administer Workforce Business Process,” Creating Checklists for more
information on how to create checklists.


Creating Organizational Relationships
All the components that enable you to add a person to the system also enable you to create their
organizational relationship. There are additional components that allow you to create new organizational
relationships for an existing person. See Appendix C for a Decision Matrix on how to determine what
relationship to create.

Components where a person can be created and/or given a new organizational relationship
Menu Location Used to Create Component Name
Workforce Administration, Create a person. PERSONAL_DATA
Personal Information, Add a Create any organizational Transfers to:
Person relationship. JOB_DATA_EMP
JOB_DATA_CWR
JOB_DATA_POI
PERS_POI_ADD
Workforce Administration, Create a person. PERSONAL_DATA
Personal Information, Create any organizational Transfer to:
Biographical, Add a Person relationship. JOB_DATA_EMP
JOB_DATA_CWR
JOB_DATA_POI
PERS_POI_ADD
Workforce Administration, Create a POI without job PERS_POI_ADD
Organizational Relationships, relationship for an existing
Add a POI Relationship person.
Global Payroll & Absence Mgmt, Create a person. GP_ADD_PERSON
Payee Data, Add a POI Payee Create a POI with job This is a front end to the
relationship for Global Payroll. PERSONAL_DATA and/or
JOB_DATA_POI components.
Stock, Add a Person Create a person. ST_ADD_PERSON
Create a POI without job This is a front end to the
relationship for Stock. PERSONAL_DATA and/or
PERS_POI_ADD components.
Enterprise Learning, Add a Create a person. TRN_ADD_PERSON front end
Person Create a POI without job to PERSONAL_DATA and/or
relationship for Administer PERS_POI_ADD
Training.


Components where a person can be created and/or given a new organizational relationship
Menu Location Used to Create Component Name
Benefits, Administer COBRA Create a person from an existing MANUAL_COBRA
Benefits, Maintain COBRA Non- dependent record. This component uses
Employees, Create COBRA Create a POI with job component interfaces:
Non-Employee relationship of COBRA To create the person using the
participant. information on the Dependent
Beneficiary component.
Create the POI with job
relationships using the
employee’s base data.

Pension, Payments, Create a person from an existing PA_RT_EMP_SETUP
Create Payee dependent record. Transfers to:
Create a POI with job RA_PERS_DATA
relationship for a Pension payee. PA_JOB
Workforce Administration, Create an employee relationship JOB_DATA_EMP
Organizational Relationships, for an existing person.
New Employment Instance
Workforce Administration, Create a contingent worker JOB_DATA_CWR
Organizational Relationships, relationship for an existing
New Contingent Worker person.
Instance
Recruiting Solutions Create a new person from an HRS_PREP_FOR_HIRE
existing Applicant record.
Create a new employee
relationship for a person.
Create a new contingent worker
Recruiting Solutions Create an external trainee HRS_ADD_EXT_TRN
Campus Community, Personal Create a person. SCC_BIO_DEMO
Information, Add/Update a Create a POI without job Uses component interfaces to:
Person relationship. Create a record in
PERSONAL_DATA.
Create the campus solutions POI
relationship data.
Campus Community, Personal Create a person. SCC_BIO_DEMO
Information (Student), Create a POI without job Uses component interfaces to:
Add/Update a Person relationship. Create a record in
PERSONAL_DATA.
Create the campus solutions POI
relationship data.

Assignment Relationship Example

This is an example of the JOB_DATA_EMP component where you enter the details of a person’s
employee relationship:


JOB_DATA_EMP component

A relationship with an assignment (job) has many attributes. Please refer to the PeopleSoft Enterprise Human
Resources 8.9, Administer Workforce PeopleBook for information on this and the other JOB components.

Non-Assignment Relationship Example


This is an example of the PER_POI_TRANS component where you would enter the details of a person’s
non-assignment relationship. In this case, we are adding an External Trainee POI relationship. This POI
type will use just this main page.

Add Person of Interest Page

Other POI types may use a different transactional record. If this is the case, then a link to that component
will appear in place of the Person of Interest History Grid.

Creating Worker Organizational Relationships and Instances
People who will have an employee or contingent worker relationship with the organization need to have
data in the core JOB tables. For these workers, it is easier to talk about organizational instances and
organizational assignments. The description of these is repeated below.

Core Job Relationship Records
Record Name Description


PER_ORG_INST Person Organizational Instance
A single instance of an organizational relationship as
defined by the customer. This organizational instance may
include more than one assignment
(PER_ORG_ASGN.EMPL_RCD).
Each controlling instance (PER_ORG_INST) controls one
or more assignments (PER_ORG_ASGN).
Each assignment (PER_ORG_ASGN) has one, and only
one, controlling instance (PER_ORG_INST).
PER_ORG_ASGN Person Organizational Assignment
This record provides a unique identification of a person and
an organizational relationship. Each separate relationship
has a unique identification ID (EMPL_RCD field) and has,
one and only one, row in PER_ORG_ASGN.
JOB Person Organizational Assignment History
This record provides an historical record of information
EMPL_RCD). Each PER_ORG_ASGN parent has at least
one JOB child row. Multiple rows can be entered for the
same day..

Department, location, business unit transfers can all be done within the history of one assignment
(EMPL_RCD), so for many people you might only ever have one instance with one assignment. The
additional instances and assignments are available when you have more complex relationships. When you
need to be able to capture different JOB attributes for someone, then you need to create a new instance
or an additional assignment. Which you create depends on your needs. The usage of different
EMPL_RCDs is required for any person who has more than one relationship type. Each EMPL_RCD
will be for one and only one PER_ORG (EMP/CWR/POI). For this reason, the HRMS system is
delivered with the PeopleTools PSOPTIONS MULTIJOB flag turned on. This flag must be ‘Y’ for the
HRMS system to work. However, you will still need to make a decision on whether you will allow
multiple EMPL_RCDs with the same PER_ORG. When we talk about ‘multiple jobs’, we are referring to
the practice of allowing multiple EMPL_RCDs within the same PER_ORG (for example, a Employee is
actively working two different assignments – both or which are employee assignments).
If you are not going to use true ‘multiple jobs’, then you will want to not give any user access to the
Global Assignments, Add Additional Assignments, Temporary Assignments, or the Additional
Appointment Japan components. You should also restrict the access to the Add Employment Instance
and Add Contingent Workers only to users who understand the way assigments work.
When a person needs to have different values for the following data active at the same time, then a new
EMPL_RCD will need to be created. If the data is just changing as a result of some event, and only one
will be active, then you would enter the change on the person’s existing EMPL_RCD in the JOB_DATA
component.
• Benefit plans
• Payroll needs
• Location, department, business unit, jobcode, salary grade etc are needed.


For many people, there will never be more than one assignment for an instance. Multiple jobs are required
where there is some special relationship between two assignments such as:
• Global home and host assignments
• Japan Kenmu appointments or Intercompany Transfers
• Temporary assignments
• Additional assignments that should not be treated as ‘hires’

You will always create a new instance when
• A new PER_ORG is used (EMP, CWR) that the person has never had
• Any new POI with a job is needed. POIs are always created as separate instances.
• Anytime you want the new assignment to be treated as a new hire (with its own hire and service
dates) and you don’t want to reactivate a terminated assignment.

We use different components to handle the different situations. This allows us to give a functional
description of the situation and a navigation reference with a more understandable name. This will hide
the complexity of the instances and assignments to some degree. You will also want to determine which
of these situations you even want to allow in your system.

Components where a new instance or assignment can be created
Component Comment
Add a Person Used when the person does not already exist in the system (does not
PERSONAL_DATA have an EMPLID in PERSON.
From within this component, the user will transfer to the appropriate
Navigation: component to create the organization relationship the user has
Workforce Administration, chosen.
Personal Information,
Add a Person For an EMP, the component will transfer to JOB_DATA_EMP.
For a CWR, the component will transfer to JOB_DATA_CWR.
For a POI, the component will transfer to PERS_POI_TRANS.
New Employee Instance This component will create a new instance and its assignment
JOB_DATA_EMP information for the EMP PER_ORG. This creates a new
EMPL_RCD.
Navigation: Allows only the action of HIR.
Workforce Administration, This component can be accessed from the left navigation directly
Job information, and from within the Add a Person component.
New Employee Instance
New Contingent Worker This component will create a new instance and its assignment
Instance information for the CWR PER_ORG. This creates a new
JOB_DATA_CWR EMPL_RCD.

Navigation: Allows only the action of ADD.
Workforce Administration,
Job information, This component can be accessed from the left navigation directly
New Continent Worker and from within the Add a Person component..
Instance


Components where a new instance or assignment can be created
Component Comment
Add Additional Assignment Creates a new assignment under an already existing (and active)
ADD_PER_ORG_ASGN instance. This is referred to as a true multiple job.

Navigation: Allows only the action of ADL.
Workforce Administration,
Job information, The user choose which instance to use and what EMPL_RCD to
Add Additional Assignment create and then transfers to the JOB_DATA_CONCUR
component.
Add Host Assignment This component is used to create a new host assignment in the
ADD_HOST_ASGN Global Assignment feature.

Navigation: Allows only the action of ASG.
Workforce Administration ,
Global Assignments The user choose which instance (Home record) to use and what
, Add a Host Assignment EMPL_RCD to create and then transfers to the
HOME_HOST_DATA component
Add an Additional This component is used to create an additional appointment for
Appointment (Japan only) Japan.
AA_MGMT_JPN

Navigation:
Workforce Administration ,
Job Information ,
Additional Appointment
Japan

Additional Assignment or New Instance?
The additional assignment relationship concept allows you to create a new assignment for a person when
they already have an existing instance and you do not want to count this new assignment as a ‘hire’.
These assignments must be tied to an existing active instance of the same PER_ORG type (employee or
contingent worker) and they will be ended if that instance is terminated. They may also be ended prior to
the instance being terminated.

Additional assignments might also be related for security access purposes. You have the ability to indicate
that you want to allow a user who has access to an instance to also have access to its assignments, or allow
a user who has access to an assignment to also have access to its instance. This makes it possible for these
users to see this related information even if they would normally not have access that row. Refer to the
PeopleSoft Enterprise HRMS 8.9: Application Fundamentals PeopleBook for more information on setting up
row level security.

There are three types of additional assignment relationships which have additional special rules. These
relationships are used under specific circumstances in order to support additional processing or data.

Global assignments enable you to assign employees to a global assignment and to monitor,
compensate, and track education and qualification for the employees and their dependents as
they move from project to project in your organization's operations in multiple countries. The


Oracle ps person_model rev 08242005

Oracle ps person_model rev 08242005

Recommended

Recommended

More Related Content

Similar to Oracle ps person_model rev 08242005

Similar to Oracle ps person_model rev 08242005 (20)

Recently uploaded

Recently uploaded (20)

Oracle ps person_model rev 08242005