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 Person Field: EMPLID Organizational Relationship Field: PER_ORG

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 1

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) Field: PER_ORG (Plural: Employees / Employed Workforce) 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) Field: PER_ORG (Plural: Contingent Workers / Contingent Workforce) 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) Field: PER_ORG A person who does not have aan employment or a contingent worker relationship but who is still of interest to the organization. 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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 2

Term

Definition by the POI_TYPE.

Person of Interest Type Field: POI_TYPE

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 Field: PER_ORG (values EMP, CWR) Organizational Instance Also known as Controlling Instance

The combination of your employees and contingent workers is collectively called your workforce (singularly, they are known as workers). An occurrence of an organizational relationship. Also referred to as an Employment Instance, a Contingent Workforce Instance, or a POI Instance. Organizational instances can be limited to one assignment (EMPL_RCD) or include multiple assignments, depending on 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.

Field: ORG_INSTANCE_ERN

Assignment Field: EMPL_RCD

A unique numeric identifier for each relationship that a person has that requires JOB information. The value of the EMPL_RCD is not used for anything other than to identify a separate relationship; it does not rank or otherwise give precedence to one assignment over another An concurrent assignment in addition to, and under an existing assignment Also referred to as Multiple Assignments. Some organizations allow their workforce to have multiple, concurrent assignments. Each of these assignments needs to be tracked under a distinct EMPL_RCD. In cases where the customer

Additional Assignment

Identified by the EMPL_RCD and the ORG_INSTANCE_ERN combination.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 3

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 EMPL_RCD will always equal the ORG_INSTANCE_ERN.

An concurrent assignment in addition to an existing assignment Some organizations allow their workforce to have multiple, 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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 4

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 5

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
PERSON

Category
Core Required

Description
Person 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 Required

Personal History 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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 6

NAMES

Core Required

Person Names. 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 Not Required

Person Addresses. 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 Not Required

Person Phone Numbers. 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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 7

EMAIL_ADDRESSES

Core Not Required

Person Email Addresses 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 Not Required

Person National Identifiers. 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 Relationship

One row is required in either PER_ORG_ASGN or PER_POI_TYPE

Each person must have at least one organizational relationship defined. 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 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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 8

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 9

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 10

Person Extension Tables Detail Record Name
DIVERSITY

Category
Extension

Description
Diversity information for Canada, the United Kingdom, and the Netherlands. A person has only one DIVERSITY row.

DIVERS_ETHNIC

Extension 0 to many

Ethnic diversity information is used by some countries. The zero to many relationship enables you to track 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 0 to many

Religion information used by some countries. The zero to many relationship enables you to track multiple religions for a person. Used by: Malaysia, Singapore, Australia, New Zealand, and India

PLACE_ORIG_CHE

Extension 0 to many

Switzerland specific extension that captures the places of origin for a person. One place must be specified as the main place of origin. German specific extension that captures nationality information for a person. Multiple nationalities can be entered.

NATIONALITY_GER

Extension 0 to many

PERSON_BRA

Extension 0 to 1

Brazilian specific extension for a person that captures voter, military, RG, and CTSP information. Only one row can be entered.

PERSON_FRA

Extension 0 to 1

French extension for a person that captures previous experience information. Only one row can be entered.

PERS_SMOKER

Extension Historical

Benefits extension for a person that captures smoking history. Brazilian extension for a person that captures information such as ethnicity, education level, and nationality, and tracks it historically. . Mexican extension for a person that captures

PERS_DATA_BRA

Extension Historical

PERS_DATA_MEX

Extension

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 11

Person Extension Tables Detail Record Name Category
Historical PERS_DATA_IND Extension Historical PERS_DATA_DEU Extension Historical PERS_DATA_FRA Extension Historical PERS_DATA_JPN Extension Historical PERS_DATA_USA Extension Historical

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

PERS_DATA_CHE

Extension Historical

PERS_DATA_ITA

Extension Historical

PERS_DATA_CAN

Extension Historical

PERS_DATA_ESP

Extension Historical

PERS_DATA_FPS

Extension Historical

PERS_DATA_USF

Extension Historical

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 12

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).

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 13

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 POI_TYPE Description 00000 Unknown JOB Reqd Comment 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. Y Used by PeopleSoft Benefits Administration for COBRA beneficiaries. These relationships can only be created on the components on the COBRA menu. Y Used by PeopleSoft Pension Administration. This relationship can only be created on the components on the Pension Administration menu. Y Used by PeopleSoft Stock Administration. Y Used by PeopleSoft Stock Administration. Y Used by the PeopleSoft Global Payroll applications. 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. 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. 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.

00001

COBRA Qualified Beneficiary

00002

Pension Payee

00003 00004 00005 00006

Stock - Board Member Stock - Non-HR Employee Global Payroll Payee Student Refund

00007

External Trainee

00008

External Instructor

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 14

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

00010

Other

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 Component Description Component Name 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) Company Property Volunteer Info General Comments Bank Accounts Training IDENTIFICATION_DATA COMPANY_PROPERTY EMPL_VOLUNTEER GENL_COMMENTS PYE_BANKACCT TRN_STUDNT_CRS_DT2

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 15

Administrator components in HRMS accessible for any Person in PS_PERSON Component Description Component Name Training Summary TRN_STUDNT_CRS_SU3 Education EDUCATION Person Checklist PERSON_CHECKLIST Accomplishments LANGUAGES Languages LICENSES_CERTIFS Licenses and Certificates MEMBERSHIPS Memberships TEST_RESULTS_PANEL Test Results HONORS_AWARDS Honors and Awards SPECIAL_PROJECTS Significant Special Projects Competencies Health and Safety Audiometric Exam Eye Exam Physical Exam Respiratory Exam Drug Test Health Card COMPETENCIES HS_EXAM_AUDIO HS_EXAM_EYE HS_EXAM_PHYSICAL HS_EXAM_RESPIRE GVT_DRUG_TEST GVT_HEALTH_CARD

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 16

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 17

Figure 3: Person Model –Organizational Relationship Summary

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 18

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 19

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:

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 20

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 21

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 Record Name Category PER_ORG_INST Core

PER_ORG_ASGN

Core

Description 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). 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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 22

Core JOB Relationship tables Record Name Category JOB Core

PER_POI_TYPE

Core

PER_POI_SCR_DT PER_POI_SCRTY

Core

Description PER_ORG_ASGN. 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. 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. Person Organizational POI Security 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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 23

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 Record Name Category Description PER_ORG_INST Core Person Organizational Instance Required A single instance of an organizational relationship as defined by the customer. PER_ORG_ASGN Core Person Organizational Assignment 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 directly related to one assignment (EMPLID / EMPL_RCD).

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 24

Assignment Tables – Core and Extension Record Name Category Description 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. Extension of Job for US Federal Data. JOB_USF Product This record has a mandatory one to one relationship with Extension 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 Contains specific data for India. This is an extension of JOB Extension 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 Contains specific non-historical official language data for Extension 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 Contains specific non-historical INSS data for Brazil. This is Extension 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 Contains specific non-historical education level data for Extension Not Required Japan. This is an extension of the PER_ORG_ASGN record and has a one-to-one relationship (when data is

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 25

Assignment Tables – Core and Extension Record Name Category Description 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).

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 26

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 Record Name Category Description 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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 27

Person Relationships without Assignments Tables Record Name Category Description 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 History Required 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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 28

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 29

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 30

Contact Information Page

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 31

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 32

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 33

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):

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 34

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 35

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 Transfers to: Personal Information, Add a Create any organizational JOB_DATA_EMP Person relationship. JOB_DATA_CWR JOB_DATA_POI PERS_POI_ADD Workforce Administration, Create a person. PERSONAL_DATA Personal Information, Transfer to: Create any organizational JOB_DATA_EMP Biographical, Add a Person relationship. 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 person. Add a POI Relationship 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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 36

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 This component uses Benefits, Maintain COBRA Non- dependent record. component interfaces: Create a POI with job Employees, Create COBRA To create the person using the Non-Employee relationship of COBRA participant. information on the Dependent Beneficiary component. Create the POI with job relationships using the employee’s base data.

Pension, Payments, Create Payee Workforce Administration, Organizational Relationships, New Employment Instance Workforce Administration, Organizational Relationships, New Contingent Worker Instance Recruiting Solutions

Create a person from an existing dependent record. Create a POI with job relationship for a Pension payee. Create an employee relationship for an existing person. Create a contingent worker relationship for an existing person. Create a new person from an existing Applicant record. Create a new employee relationship for a person. Create a new contingent worker relationship for a person. Create an external trainee relationship for a person. Create a person. Create a POI without job relationship.

PA_RT_EMP_SETUP Transfers to: RA_PERS_DATA PA_JOB JOB_DATA_EMP JOB_DATA_CWR

HRS_PREP_FOR_HIRE

Recruiting Solutions Campus Community, Personal Information, Add/Update a Person

HRS_ADD_EXT_TRN SCC_BIO_DEMO Uses component interfaces to: Create a record in PERSONAL_DATA. Create the campus solutions POI relationship data. SCC_BIO_DEMO Uses component interfaces to: Create a record in PERSONAL_DATA. Create the campus solutions POI relationship data.

Campus Community, Personal Information (Student), Add/Update a Person

Create a person. Create a POI without job relationship.

Assignment Relationship Example

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 37

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 38

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 39

PER_ORG_INST

PER_ORG_ASGN

JOB

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). 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. 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..

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.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 40

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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 41

Components where a new instance or assignment can be created
Component Add Additional Assignment ADD_PER_ORG_ASGN Navigation: Workforce Administration, Job information, Add Additional Assignment Add Host Assignment ADD_HOST_ASGN Navigation: Workforce Administration , Global Assignments , Add a Host Assignment Add an Additional Appointment (Japan only) AA_MGMT_JPN Navigation: Workforce Administration , Job Information , Additional Appointment Japan Comment Creates a new assignment under an already existing (and active) instance. This is referred to as a true multiple job. Allows only the action of ADL. The user choose which instance to use and what EMPL_RCD to create and then transfers to the JOB_DATA_CONCUR component. This component is used to create a new host assignment in the Global Assignment feature. Allows only the action of ASG. The user choose which instance (Home record) to use and what EMPL_RCD to create and then transfers to the HOME_HOST_DATA component This component is used to create an additional appointment for 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

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 42

instance is also referred to as the HOME assignment and the additional assignment as the HOST assignment within this module. Refer to the PeopleSoft Enterprise Human Resources 8.9: Track Global Assignments PeopleBook for more information. Japan additional assignments (also known as Kenmu) are special relationships used by Japanese companies. These may include intercompany transfers or external company transfers. When additional appointments exist in conjunction with intercompany transfers, for example when you serve as a hosting company, you can store information about additional appointments that your transferee may have in the home company, as well as any additional appointment information within your company as host. It also allows you to track cost distributions among a main appointment (the instance) and its additional assignments. Refer to PeopleSoft Enterprise Human Resources 8.9: Administer Workforce PeopleBook Section (JPN) Tracking Additional Appointments (Kenmu). Temporary assignments are a special type of relationship where the person’s substantive job (the Instance) is put on hold for the duration of the temporary assignment. When a worker covers the responsibilities of another job besides the substantive job, the worker works a temporary assignment. Temporary assignment data must be tracked the same way that substantive job data is tracked. For example, a person hired into a teaching appointment takes this as the substantive job. The person then receives a one month temporary assignment as a department head. The original teaching position is suspended for the duration of the temporary assignment. It is also possible that the person takes a temporary assignment on a partial basis. The person might retain the substantive teaching position for twenty hours a week while also working the temporary assignment as department head for the other twenty hours. The person cannot work beyond the forty-hour workweek, but any combination of assignments might be entered to fill the forty hours. Please refer to the PeopleSoft Enterprise Human Resources 8.9: Administer Workforce PeopleBook Section Entering Additional Information in Human Resources Records for more information. The fourth type of additional assignment is used when you want to give a worker a new assignment at the same time that he is still active in another assignment. You can choose to create this new assignment as a new instance or as an additional assignment for a controlling instance. Which you choose will depend on whether you want to take advantage of the benefits of relating two assignments. However, there are also some restrictions on additional assignments. Benefits of additional assignment relationships are: • • • The new assignment will not be counted as a ‘hire’ for regulatory reporting and date setting The new assignment will be automatically terminated when the controlling instance is terminated. You can allow the users who have access to the controlling instance to also have access to the additional assignment or vica versa with just a installation setting on security.

The restriction of using the additional assignment relationships is: • The additional assignment cannot remain active, or be reactivated if the controlling instance is in an inactive status.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 43

You should always create a new instance unless the benefits are worth it.

Instance Dates versus Assignment Dates

An assignment is related to an instance because it is not a true ‘hire’ record. Therefore, it doesn’t have a hire or latest hire date. It inherits those dates from its controlling Instance. There are also dates that are stored at the instance level that are used for other purposes. It is important to understand the difference between these dates when you use them for reporting.

Field HIRE_DT

Meaning First date that this EMPLID/EMPL_RCD was hired (or started as a CWR) into an instance. Does not get a value for EMPL_RCDs created as ADL or ASG. Set when action of HIR is used. Latest date that this EMPLID/ EMPL_RCD was hired or re-hired (or started or re-started as a CWR) into an instance. Does not get a value for EMPL_RCD s created as ADL or ASG. Set when action of HIR or REH is used. First date this EMPLID/ EMPL_RCD was started (either as hire or additional assignment). Always gets a value.

LAST_HIRE_DT

ASGN_START_DT

LST_ASGN_START_DT

Latest date that this EMPLID/ EMPL_RCD was started or restarted. Always gets a value.

TERMINATION_DT ORIG_HIRE_DT

If on the instance, then this is the also the date the instance was terminated or completed. Earliest date that this EMPLID/ERN INSTANCE was associated with the organization - regardless of what the EFFDT is for the first row in JOB. Customers can enter an earlier date here than the earliest JOB.HIRE_DT.

Hire versus Latest Hire

In this example, EMPLID A001 was first hired into the organization on May 1, 1960. He then terminated on Oct 01, 1970 and then rehired on Nov 01, 1980.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 44

Because the action of REH (Rehire) was used to bring him back on the same instance, the HIRE_DT is not changed. The LAST_HIRE_DT is changed to be the effective date of the rehire. If you ran a report that used the HIRE_DT field it would show May 1, 1960 – not the latest hire date of Nov 01, 1980. Note the same relationship between the ASGN_START_DT and LST_ASGN_START_DT fields. LST_ASGN_START_DT will reflect the latest start date.

Instance dates versus the Assignment dates

When you look at the JOB row of an instance, you see that the instance dates are the same as the assignment dates. But when you look at an additional assignment row, there are no values in the HIRE_DT and LAST_HIRE_DT fields. This is because the additional assignment record does not get these dates because it does not constitute a hire.

Instance Dates

Assignment Dates

When you use a view like EMPLOYMENT or PER_ORG_ASGN_VW, the fields HIRE_DT and LAST_HIRE_DT on an Assignment row will be populated from that assignments Instance record fields. For most reporting using the fields ASGN_START_DT or LST_ASGN_START_DT will be sufficient. But if you need to report the actual legal hire (or latest hire) for an additional assignment, you should use the HIRE_DT or LAST_HIRE_DT from the view PER_ORG_ASGN_VW.

Instance and Assignment on the EMPLOYMENT Information Page in JOB_DATA

You can see the values for these fields in the JOB_DATA Component on the Employment Information data page. On an instance record, the data in both group boxes will have the same dates. Note that you can modify the ORIG_HIRE_DT (Original Start Date field) and ORG_INST_SRV_DT (Org Instance Service Date field) dates if you wish.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 45

Employment Information page with an instance row

On an additional assignment record, the data in the organizational instance will be displayed from the instance record – and is not updateable.

Employment Information for an additional assignment record

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 46

Multiple Organizational Relationships – an Example

A person can have many different organizational relationships either concurrently or consequently. This section will give you an example of how this might happen. The diagram below shows the different relationships that John Summers has had with the organization.

Multiple organizational assignments

1.

John Summers attends a training class at company XYZ on May 1, 1995 as an external trainee. 1b The external trainee instance is closed

2.

John Summers becomes a contingent worker at company XYZ on Oct 10, 1996. 2b He completes his contingent worker assignment on Aug 20, 1999.

3. 4.

John Summers becomes an employee at company XYZ on Sept 3, 1999 John Summers gets an additional assignment at company XYZ in his original business unit on Nov 1, 2001 that should not be counted as a new hire 4b He completes his additional assignment on Mar 4, 2001.

5.

John Summers starts as an employee on Feb 2, 2002 in a different business unit with the organization that requires this start to be counted as a new hire.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 47

The actual completion dates of each assignment are irrelevant to the relationships of the instances and assignments except for the additional assignment in #4. John could have an active contingent worker instance and an active employment instance at the same time. However, to add the additional assignment to the employment instance with the OIN (Org Instance ERN) of 1, that instance must still be active. Each instance is treated completely separately. There are no connections between them. Additional assignments are directly related to their controlling instance. They can only be active if the controlling instance is active. They can be terminated prior to the controlling instance, but if the instance is terminated then any active additional assignments for it will also be terminated by the system. Note: The value that is used for the next instance’s ORG_INSTANCE_ERN is whatever the next available EMPL_RCD is for this person. We could not add an additional key to the JOB (or PER_ORG_ASGN) records so the relationship between the instance and its assignments is via a logical foreign key (the ORG_INSTANCE_ERN). To make the numbering simplier (and to allow for changes to the relationships between instances and assignments in the future), we chose to always have the controlling assignment for an instance have the same value in its EMPL_RCD and ORG_INSTANCE_ERN. The ORG_INSTANCE_ERN is not a sequence number – as in “This is the John’s second instance”. It is just a unique identifier that ties an assignment with its instance and identifies which assignment is the controlling assignment. Likewise, the value of the EMPL_RCD does not have any functional meaning – it is just a way of choosing a unique identifier for an assignment. EMPL_RCD 0 (zero) does not have any significance in the Enterprise HCM products – its simply where we chose as the default to start the automatic numbering.

Here is what happens in the database at each step. (1) John Summers attends a training class at company XYZ on May 1, 1995 as an external trainee. We determine that John Summers does not already exist as a person in the database, so we create a Person ID for John Summers and an organizational relationship of External Trainee using the Add a Person menu item. This POI type does use a JOB row so no EMPL_RCD is assigned to this instance.

Record
PERSON

Fields
EMPLID 1001

PERS_DATA_EFFDT

EMPLID 1001

EFFDT 5/1/1995 Name Type Primary EFFDT 5/1/1995 NAME Summers,John

NAMES

EMPLID 1001

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 48

PER_ORG_TYPE

EMPLID 1001

POI Type External Trainee

PER_POI_TRANS

EMPLID 1001

POI Type External Trainee

EFFDT 5/1/1995

Status Active

1b. When we want to inactivate this external trainee instance we would enter a row in PER_POI_TRANS for that date and an effective status of inactive. PER_POI_TRANS
EMPLID 1001 POI Type External Trainee EFFDT 5/2/1995 EFF Status Inactive

(2) John Summers becomes a contingent worker at company XYZ on Oct 10, 1996. John Summers already exists in the system so a new ID is not created (although the person information would be updated at this point to make sure that it is current). John does not have a Contingent Worker instance at this time, so we create a new contingent worker instance for EMPLID 1001. The next available EMPL_RCD for this person is 0 (zero). This will be used for both the instance and the assignment. We would use the New Contingent Worker Instance menu item.

Record
PER_ORG_INST

Fields
EMPLID 1001 OIN 0 ERN 0 ERN PER_ORG CWR OIN 0 EFFDT PER_ORG CWR Action Hire/Start Date 1001 0 10/10/1996 ADD 10/10/1996 Asgn Start Dt 10/10/1996 Term Dt

PER_ORG_ASGN

EMPLID 1001

JOB

EMPLID

2b. When John Summers completes his contingent worker contract we would enter a row into JOB with the completion action. JOB
EMPLID 1001 ERN 0 EFFDT 8/20/1999 ACTION COM Hire Dt 10/10/1996 Asgn start 10/10/1996 Term Date 8/19/1996

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 49

(3) John Summers becomes an employee at company XYZ on Sept 3, 1999 We find John Summers exists as a person under ID 1001. He does not have an active Employee Instance, so we need to create a new one using the New Employee Instance menu item. The next available EMPL_RCD for him is 1.

Record
PER_ORG_INST

Fields
EMPLID 1001 OIN 1 ERN 1 ERN PER_ORG EMP OIN 1 EFFDT PER_ORG EMP Action Hire Dt Asgn Start Term Dt 1001 1 9/3/1999 HIRE 9/3/1999 9/3/1999

PER_ORG_ASGN

EMPLID 1001

JOB

EMPLID

(4) John Summers gets an additional assignment at company XYZ on Nov 1, 2001 John has an active employee instance under the Org Instance 1. We decide that we want this new assignment to be treated as an additional assignment not as a separate hire. We use the Add Additional Assignment menu item and choose the employee instance that we want this assignment associated with. The next available EMPL_RCD will be defaulted in (in this case 2). Nothing will be altered on the PER_ORG_INST record for 1001/1, but the system does create a new PER_ORG_ASGN and JOB rows.

Record
PER_ORG_INST

Fields
EMPLID 1001 OIN 1 ERN 2 ERN PER_ORG EMP OIN 1 EFFDT PER_ORG EMP Action Hire Date Asgn Start Term Dt 1001 2 11/1/2001 ADL 11/1/2001

PER_ORG_ASGN

EMPLID 1001

JOB

EMPLID

Note: if you asked for ERN 2’s Hire date it would be Sept 3, 1999 (the one under the controlling instance #1). If you ask for ERN 2’s Assignment Start date, it would be Nov 1, 2001.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 50

(5) John Summers starts as an employee on Feb 2, 2002 with company XYZ in another business unit where we want to treat this as a new hire there. John does have an active employment instance that we could make this new assignment an additional assignment under. But in this case, it is another Business Unit which has a requirement to report this as a new hire. We would use the New Employment Instance menu item to create a new employment instance for EMPLID 1001. The next available EMPL_RCD will be defaulted in (which is now 3).

Record
PER_ORG_INST

Fields
EMPLID 1001 OIN 3 ERN 3 ERN PER_ORG EMP OIN 3 EFFDT PER_ORG EMP Action Hire Dt Asgn Start Term Dt 1001 3 2/2/2002 HIRE 2/2/2002 2/2/2002

PER_ORG_ASGN

EMPLID 1001

JOB

EMPLID

Note: if you asked for ERN 3’s Hire Date it would be Feb 2, 2002

Using a Component Interface or service to create a person. If you are using a component interface process to create a person, the process is responsible for creating at least one organizational relationship at the time it creates the person. The system does not automatically create an Unknown POI row for a person when you use a component interface process because of performance considerations. There are many batch processes that can create many people at a time and the overhead of creating the Unknown POI and then later deleting it is unwanted when the batch process is capable of generating the Unknown POI only if it fails to create another relationship.
Promoting an Assignment to an Instance

Note: The ability to promote an assignment to an instance requires the application of the 8.9 resolution 627868 when it is available – currently targeted for inclusion in the HRMS HR 8.9 Product Resolution Bundle #4 (as of August 2005).

Sometimes you will want to take an additional assignment and remove its relationship to its controlling instance. This is possible to do under certain circumstances for normal additional assignments and host assignments:

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 51

• • • •

Japan additional appointments cannot be promoted Temporary assignments cannot be promoted Host assignments must be inactive at the time of the promotion Normal additional assignments can be promoted when active or inactive.

To promote a Host assignment, an assignment complete action (ASC) must first be entered in the HOME_HOST_DATA component. You then enter the promotion in JOB_DATA followed by a HIR action. The JOB_DATA component can be used to promote the assignment. Enter a new JOB effective dated row, and choose the “Promote Assignment to Instance” action (OCA) and save the component. A new Instance will be created with the same number as the EMPL_RCD, the Original Start Date and First Start Date on the Instance will be set to the First Assignment date of the original assignment. These can be overridden as normal on the EMPLOYMENT page.

Note: Once an assignment has been promoted, it cannot be returned to an additional assignment relationship. There is no history of the instance it used to be associated with. An enhancement that is being considered is the ability to demote an instance to be an assignment related to another instance. This has not been approved as of yet.

Reviewing a Person’s Organizational Relationships

Because a single person can have many different relationships some of which have additional assignments, we created a component that will allow a user to see all of these relationships with basic information on each. The user must have access to this person through row level security, but if they do they will be able to see this information on all of the relationships the person has. Component: PERSON_ORG_SUMM Navigation: Workforce Administration, Person Organizational Summary

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 52

Person Org Summary page

Notice that there are two rows in the Employment Instances group box. This means that Joel Summers has two separate employment instances. The first one has two assignments related to it – the main one and an additional assignment. If we click on the next icon we can see his other employment Instance.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 53

Person Org Summary page

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 54

SETUP TABLES Person of Interest Type Setup Table

Record Description

POI_TYPE_TBL This setup table holds the definition of the person of interest types. Each POI type has several attributes, which determine how they are used in the system. You can make any of the delivered types inactive ( except the Unknown type) , change the descriptions, and add additional types. POI_TYPE_LNG POI_TYPE_TBL Set Up HRMS, Foundation Tables, Organization, Person of Interest Type

Related Language Component Navigation

POI_TYPE_TBL Record field display

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 55

Person of Interest Type table page

Description and Short Description (required) The description for the type – this will be used in drop downs for the POI_TYPE field. Effective Status (required) Determines whether this POI type is allowed in the your database. Job Record Required Indicates whether this POI_TYPE will need an assignment (JOB) or not. Record for POI Transaction: This is the transaction record that the history, status or other information can be captured for this POI type. Either a product specific record or the generic PER_POI_TRANS record must be specific. Component Name: The component where the POI transaction record is maintained. Menu/Page Info:

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 56

The specific location in the menuing system where this component is located. The component will be transferred to using the PeopleCode TransferComponent command. Record for the POI Summary View: This is the view used in the PERSON_ORG_SUMM component to populate the POI Relationships group box. Each POI_TYPE needs to have a summary view in the proper format for it to be reflected on the summary page. This view must use the POI_VW_SBR as its record definition and map the proper data into the fields (if available – otherwise map a blank).

POI_OTH_VW: Record Use View

Person of Interest Checklist: What checklist to default in on the Add a Person Relationship pages when this POI type is chosen. These pages vary based on the product. Examples are TRN_ADD_PERSON and ST_ADD_PERSON. Allow in Generic Add Component: Determines whether this POI type will be available in the dropdown list of types in the PERSONAL_DATA component. Since some POI types must be created via specific product specific components, we need to be able to restrict those from being chosen here. Allow in Generic Update Component: Determines whether this POI type will be maintainable in the PERS_POI_MAINTAIN component. Some POI types must be modified via specific product specific components; we need to be able to restrict those from being chosen here. Comment: Additional notes on the POI type.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 57

Person Object Installation Setup Table

Record Description

INSTALL_PERSON This setup table is used define how (or if) the person checklist feature will be used within PERSONAL_DATA and also whether an automatic search/match of possible duplicate people will be done when you save a person. There will be only one row in INSTALL_PERSON

Related Language Component Navigation

none INSTALL_PERSON Set Up HRMS, Install, Person Object Installation

INSTALL_PERSON Record Field Display

JOB Actions

Every JOB row requires an ACTION field to be captured to explain what is changing. These actions have a lot of rules associated with them that may determine the setting of the HR_STATUS and EMPL_STATUS fields, the assignment dates, and validation rules. In HRMS 8.9, we have captured these rules in a table associated with the ACTION value instead of being hardcoded in PeopleCode. The ACTION_TBL contains the actions and whether they are active (not all actions are needed by all customers or products). The rules that are applied based on the actions are in a new table called ACTION_STAT_TBL. This table has one row per action.

Record Description Related Language Component Navigation

ACTION_TBL This setup table contains the actions that are available in the JOB pages. ACTION_LNG ACTION_TBL Set Up HRMS, Product Related, Workforce Administration, Actions

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 58

ACTION_TBL Record use display

Record Description

ACTION_STAT_TBL This setup table contains the rules for status and validation of actions that are available in the JOB pages.

ACTION_STAT_TBL Record field display

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 59

Component

Actions page

The ACTION_TBL is updated in the first group box. The ACTION_STAT_TBL table is updated in the other sections. If the Action sets Status Fields checkbox is on, then you will see the status and date group boxes.
Status and Dates

An action can affect the status fields by causing a change in the Payroll Status (Active, Leave, Leave with Pay, Suspended, Retired, Retired with Pay, Terminated, etc.) and the HR Status (Active, Inactive). When these statuses are changed, the various dates associated with the assignment may change as well. These effects are identified on this page. For example, the action HIR (Hire) will cause the Payroll Status and the HR Status to be set to active. The Instance Start Date field and Instance Latest Start Date field will be set to the JOB.EFFDT. The Instance Termination Date field will be set to null. The Assignment Start field and Latest Start Date field will also be set to the JOB.EFFDT and the other assignment dates will be set to null.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 60

But if we look at the action of ADL (Additional Job) below, the instance dates are not affected. Remember that an additional job does not store hire dates – it uses the hire dates of the instance that it is related to.

Action page (partial)

And if we look at the LOA (Leave of Absence) action, the only date it causes to change is the Last Date Worked field – but notice that the Payroll Status field is set to Leave of Absence while the HR Status field is still active. A person who is on leave of absence still has an active employment relationship.

Action page (partial)
Validation Rules

The final group box on the action page shows the validation rules for this action.

Action page (partial)

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 61

If we return to the HIR action, we can see that this action is only valid for the Organizational Relationship of employee. The HIR action cannot be used for contingent workers or persons of interest. Another rule is that the previous HR Status must be inactive. You cannot use HIR on the same EMPL_RCD if it is already active. The error message for the Valid if PER_ORG is field is hardcoded in the PeopleCode, but the message for the Previous HR or Pay status fields are identified on this table. If we look at the LOA (leave of absence without pay) action validation rules,

Action page (partial)

we can see that this action is valid for any organizational relationship. But it is only valid if this EMPLID/EMPL_RCD is currently in an active HR status. Note that there is no validation on the pay status which means that if the previous payroll status was leave with pay, it is okay to change to leave without pay.

Actions that are delivered as system data cannot be modified by the customer except to change the description or to make them active or inactive. But with the addition of this table, it is easier for you to create their own actions without having to customize any PeopleCode. There are some rules that cannot be changed (such as the relationship between the payroll status and the HR status) and some of the date relationships. This is because this data is assumed throughout the system in processing and views and would require customization to change.

Creating your own Action

If you wanted to create a Leave of Absence action that was valid for only employees, you could make the system delivered LOA inactive and create your own version.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 62

Actions page

The values you choose on the instance dates will set the values for the assignment dates – you cannot override those. There needs to be a very specific relationship between instances and assignments.

Relationships between actions

There are many different business relationships that occur between specific actions. The following table lists the actions that are used to “start” a particular status and what actions can be used to “end” that status. Pairs of Actions that have an effect on the fields HR_STATUS and EMPL_STATUS PER_ORG Employee Use this Action to Start HIR - Hire To create a new instance Or to force the hire and service dates to restart Use this Action to End TER - Termination TWP – Term with Pay TWB – Term with Benefits RET – Retirement

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 63

Pairs of Actions that have an effect on the fields HR_STATUS and EMPL_STATUS PER_ORG Contingent Worker Use this Action to Start ADD – Add To create a new instance Or to force the start and service dates to restart ADL – Additional Job Create an additional assignment related to aniInstance. REH – Rehire To rehire an employee using an existing instance RNW – Renew To restart a contingent worker using an existing instance Use this Action to End RWP – Retirement with Pay COM - Completion TER - Termination TWP – Term with Pay TWB – Term with Benefits RET - Retirement RWB – Retirement with Benefits COM – Completion TER - Termination TER - Termination TWP – Term with Pay TWB – Term with Benefits RET - Retirement RWB – Retirement with Benefits COM - Completion TER - Termination TWP – Term with Pay TWB – Term with Benefits RET - Retirement RWB – Retirement with Benefits ASC – Assignment Completion

Employee or Contingent Worker Employee

Contingent Worker

Employee

ASG – Assignment Create a host assignment related to a home assignment

The next table lists other types of relationships between specific actions. Other Core Action value Pairs Action LOA – Leave of Absence LWP – Leave with Pay LTD – Long Term Disability with Pay LTO – Long Term Disability STO – Short Term Disability STD – Short Term Disability with Pay SWB – Short Work Break RFW – Return from Short Work Break REC – Recall from Layoff of Suspension These actions are used by the Education and Government customers. These actions are used to put an assignment into a suspended or laid-off status and then return RFD – Return from Disability Reversal Action RFL – Return from Leave Comment These leave actions can only be stopped using the RFL action. These leaves that are caused by a disability can only be stopped by the RFD action.

LOF – Layoff SUS – Suspension

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 64

Other Core Action value Pairs Action Reversal Action Comment the assignment to an active status. TAS – Create Temporary Assignment RFA – Return from Temporary Assignment These are the actions that will create and stop the special temporary assignment relationship that puts the original instance in a suspended status while the person works on a temporary assignment. These are the actions that will create and stop the special temporary assignment relationship that puts the original instance in a suspended status while the person works on a temporary assignment.

SUB – Create Substantive Job

RTS – Return to Substantive Job

PERSONAL_DATA Snapshot Reporting Table

In Release 8.3, the physical PERSONAL_DATA core record was replaced by the PERSON core table. The PERSONAL_DATA table is now used for two purposes. The first is for the related display of the NAME field in the PeopleTools User Profile page (USER_MAINT component) The second is for customer written processes and pages. In order to support these usages, the PERSONAL_DATA table needs to be kept in sync with the core and extension PERSON tables. Other than the PeopleTools usage, HRMS does not use this table for reporting. The data in this snapshot is always the current data for all persons in the PS_PERSON table – this includes workers and non-workers, active or not. You can choose what data will actually be stored using this setup page. The settings are stored in the PERSON_DT_SETUP record, which will have one row. This row is delivered as system data with the default settings. Record Description Related Language Component Navigation PERSON_DT_SETUP This setup table which defines what fields will be maintained in the PERSONAL_DATA snapshot table. none PERSON_DT_SETUP Set Up HRMS , System Administration, Database Processes, PERSONAL_DATA Settings

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 65

PERSON_DT_SETUP Record field display

PERSONAL_DATA settings page

If your site does not have your own references to PERSONAL_DATA, then you should not turn on any of the additional data settings in the PERSONAL_DATA options setup page. This will reduce the size and the processing time needed for the table. If you do have your own references to PERSONAL_DATA, then you can minimize the size and processing time by choosing to have only the data that you need updated in the snapshot table. You do need to create the table with the minimum data

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 66

values for the EMPLID and NAME fields in order to have the related display for a User’s name in the USER_MAINT component.

The PERSONAL_DATA table always stores the current data for a person with data coming from the following tables: PERSON PERS_DATA_EFFDT NAMES where NAME_TYPE = ‘PRI’

Table where data for the PERSONAL_DATA snapshot fields will come from Field Name Table the data is loaded from Address Type ADDRESSES where ADDR_TYPE = ‘your choice’ Other Address Type ADDRESSES where ADDR_TYPE = ‘your choice’ Include Installed Countries PERS_DATA_CAN PERS_DATA_DEU PERS_DATA_ESP PERS_DATA_FRA PERS_DATA_ITA PERS_DATA_JPN PERS_DATA_USA Include Primary Phone Data PERSONAL_PHONE where PREF_PHONE_FLAG = ‘Y’ Include Smoker Data PERS_SMOKER Include Campus Solutions Data PERSON_SA Include US Federal Data PERS_DATA_USF

How the PERSONAL_DATA table is updated

Real-Time The PERSONAL_DATA snapshot table is updated in real-time from the PERSONAL_DATA component and it’s component interfaces. These processes cause an Application Engine to be run for the EMPLID that was modified. This process is PERS_REFRESH. The process will check what the settings are in PERSON_DT_SETUP to determine which table(s) to load data from.

On-Demand The PERS_REFRESH process can be run at any time to refresh the entire PERSONAL_DATA snapshot table. Navigate to Set Up HRMS, System Administration, Database Processes, Refresh Personal Data. Create a run control record and run the process. All people in the PERSON table will be inserted into a temp table and then the data from the other records is updated to that temp table. When all data has been inserted, the PERSONAL_DATA table is truncated and the data from the temp table is copied to PERSONAL_DATA.

Future-dated rows

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 67

Several of the tables that have data that are copied to the PERSONAL_DATA table have effective dating. This means future dated rows can be entered. The PERSONAL_DATA table only contains the current data. To capture the future dated rows when they become effective, we need a process that will run every night. This Application Engine process is called HR_PERSDATA. In addition to catching the newly current data, the process will also capture any changes made to the records that weren’t captured by the real-time process (in case something was updated outside of the core component or its interfaces). Navigate to Set Up HRMS, System Administration, Database Processes , Update Personal Data - Future. Create a run control and create a daily recurrence to run shortly after midnight. The process will identify all people who: • • Are not already in the PERSONAL_DATA record Have had a data change in the PERSON table or its non-effective dated children that have been changed since the last time the row in the PERSONAL_DATA table was changed on that person. Have a max(EFFDT) less than or equal to the rundate and aren’t reflected in the PERSONAL_DATA table yet.

If you are using a version of the PERSON_BASIC_SYNC message that uses the PERSONAL_DATA record, this message will also be published so that the systems using it will get the newly effective data.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 68

POI Organization Summary Views

Each POI type must have its own view that is used in the PERSON_ORG_SUMM (Person Organizational Summary) Component. This view needs to have a standard structure for each even though the data will come from different places.

Summary Views for each POI type POI Type Description Transaction Record Summary View

00000 00001 00002 00003 00004 00005 00006 00007 00008 00009 00010

Unknown

PER_POI_TRANS

POI_UNK_VW POI_CBR_VW POI_PA_VW POI_ST1_VW POI_ST2_VW GP_POI_VW POI_CS2_VW POI_TRN1_VW POI_TRN2_VW POI_CS1_VW POI_OTH_VW

COBRA Qualified Beneficiary JOB Pension Payee Stock - Board Member Stock - Non-HR Employee Global Payroll Payee Student Refund External Trainee External Instructor Campus Solution Person Other JOB JOB JOB JOB JOB PER_POI_TRANS TRN_INSTRCT_TBL STDNT_CAREER PER_POI_TRANS

All of the views must use the POI_VW_SBR as its record definition

POI_OTH_VW view showing the POI_VW_SBR subrecord

and map the proper data into these fields. The views will be loaded into one grid in the component where we show the POI type and the EMPL_RCD (if any). In addition we show the effective status, the start

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 69

date and the end date (or expected end date) if this information can be obtained from the POI type’s transaction record.

Summary view name and SQL for each POI Type Summary View POI_UNK_VW
SQL Text
SELECT DISTINCT A.POI_TYPE , A.EMPLID , ' ' ,A.EFF_STATUS ,A.EFFDT ,A.EXPECTED_END_DATE FROM PS_PER_POI_TRANS A , PS_POI_TYPE_TBL B WHERE A.POI_TYPE = B.POI_TYPE AND B.RECNAME_POI_VW = 'POI_UNK_VW' AND A.EFFDT = ( SELECT MAX(EFFDT) FROM PS_PER_POI_TRANS B WHERE A.EMPLID = B.EMPLID AND A.POI_TYPE = B.POI_TYPE AND B.EFFDT <= %CurrentDateIn) SELECT '00001' , O.EMPLID , %NumToChar(O.EMPL_RCD) , O.HR_STATUS , O.LST_ASGN_START_DT , %DateNull FROM PS_BEN_PROG_PARTIC BP , PS_PER_ORG_ASGN_VW O WHERE BP.COBRA_EVENT_ID<>0 AND O.EMPLID=BP.EMPLID AND O.BENEFIT_RCD_NBR=BP.EMPL_RCD AND O.PER_ORG='POI' SELECT DISTINCT '00002' , A.EMPLID_PAYEE , %NumToChar(A.EMPL_RCD_PAYEE ) ,J.HR_STATUS ,J.LST_ASGN_START_DT ,J.TERMINATION_DT FROM PS_PA_RT_EMP_SETUP A , PS_PER_ORG_ASGN_VW J WHERE A.EMPLID_PAYEE = J.EMPLID AND A.EMPL_RCD_PAYEE = J.EMPL_RCD AND J.POI_TYPE = '00002' SELECT DISTINCT '00003' , J.EMPLID , %NumToChar(J.EMPL_RCD ) ,J.HR_STATUS ,J.LST_ASGN_START_DT ,J.TERMINATION_DT FROM PS_PER_ORG_ASGN_VW J WHERE J.PER_ORG = 'POI' AND J.POI_TYPE = '00003' SELECT DISTINCT '00004' , J.EMPLID , %NumToChar(J.EMPL_RCD ) ,J.HR_STATUS ,J.LST_ASGN_START_DT ,J.TERMINATION_DT FROM PS_PER_ORG_ASGN_VW J WHERE J.PER_ORG = 'POI' AND J.POI_TYPE = '00004' SELECT DISTINCT '00005' ,A.EMPLID ,%Sql(FUNCLIB_HR_CHAR,(A.EMPL_RCD)) ,J.HR_STATUS

POI_CBR_VW

POI_PA_VW

POI_ST1_VW

POI_ST2_VW

GP_POI_VW

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 70

Summary view name and SQL for each POI Type Summary View
SQL Text
,J.LST_ASGN_START_DT ,J.TERMINATION_DT FROM PS_JOB A , PS_PER_ORG_ASGN_VW J WHERE A.EMPLID = J.EMPLID AND A.EMPL_RCD = J.EMPL_RCD AND J.PER_ORG = 'POI' AND A.PAY_SYSTEM_FLG = 'GP' AND A.EFFDT = J.EFFDT_NOKEY AND A.EFFSEQ = J.EFFSEQ_NOKEY AND J.POI_TYPE = '00005' SELECT DISTINCT '00006' , J.EMPLID , %NumToChar(J.EMPL_RCD ) ,J.HR_STATUS ,J.LST_ASGN_START_DT ,J.TERMINATION_DT FROM PS_PER_ORG_ASGN_VW J WHERE J.PER_ORG = 'POI' AND J.POI_TYPE = '00006' SELECT DISTINCT '00007' , B.EMPLID , ' ' ,B.EFF_STATUS ,B.EFFDT ,%DateNull FROM PS_PER_POI_TRANS B WHERE B.POI_TYPE = '00007' AND B.EFFDT = ( SELECT MAX(EFFDT) FROM PS_PER_POI_TRANS A WHERE A.EMPLID = B.EMPLID AND A.POI_TYPE = B.POI_TYPE AND B.EFFDT <= %CurrentDateIn) SELECT DISTINCT '00008' , P.EMPLID , ' ' ,A.EFF_STATUS ,A.EFFDT ,%DateNull FROM PS_PER_POI_TYPE P LEFT OUTER JOIN PS_TRN_INSTRCT_TBL A ON P.EMPLID = A.INSTRUCTOR_ID AND 'E' = A.INTERNAL_EXTERNAL AND A.EFFDT = ( SELECT MAX(EFFDT) FROM PS_TRN_INSTRCT_TBL B WHERE A.INSTRUCTOR_ID = B.INSTRUCTOR_ID AND B.EFFDT <= %CurrentDateIn) WHERE P.POI_TYPE = '00008' SELECT DISTINCT '00009' , P.EMPLID , ' ' ,'A' ,%DateNull ,%DateNull FROM PS_PER_POI_TYPE P LEFT OUTER JOIN PS_STDNT_CAREER A ON P.EMPLID = A.EMPLID WHERE P.POI_TYPE = '00009' SELECT DISTINCT A.POI_TYPE , A.EMPLID , ' ' ,A.EFF_STATUS ,A.EFFDT ,A.EXPECTED_END_DATE FROM PS_PER_POI_TRANS A , PS_POI_TYPE_TBL B

POI_CS2_VW

POI_TRN1_VW

POI_TRN2_VW

POI_CS1_VW

POI_OTH_VW

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 71

Summary view name and SQL for each POI Type Summary View
SQL Text
WHERE A.POI_TYPE = B.POI_TYPE AND B.RECNAME_POI_VW = 'POI_OTH_VW' AND A.EFFDT = ( SELECT MAX(EFFDT) FROM PS_PER_POI_TRANS B WHERE A.EMPLID = B.EMPLID AND A.POI_TYPE = B.POI_TYPE AND B.EFFDT <= %CurrentDateIn)

The POI_OTH_VW does not hardcode in a specific POI_TYPE. This is so that it can be used by customer created POI types that use the generic PER_POI_TRANS record. This way you do not have to create your own view if you create new POI_TYPES.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 72

APPENDICIES

Appendix A:

Adding a New POI Type

You can easily add new person of interest types that do not need an assignment record. Customers may want to track data on a person for many different reasons beyond those people who are part of their workforce. For example, a casino may want to track their High Rollers; or a university may want to track library cardholders. If all you need to do is to capture some very basic information on these people, you may not need to do any customizations. Component: Navigation: POI_TYPE_TBL Set Up HRMS ,Foundation Tables, Organization, Person of Interest Type

Enter a new POI_TYPE code. We recommend that you start your numbers at 10000 or above – or use a letter prefix to avoid being overwritten by later System delivered values. Enter a Description and Short Description. Identify if a Job record is required. We do not recommend that customers create new POI rypes that use an assignment/JOB record. The reason for this is that this would also require customizing PeopleCode within the JOB_DATA components or batch processing as well.

For the Record for POI Transaction, enter PER_POI_TRANS. This is the generic transaction history record for persons of interest. When you tab out of this field, the system will enter the component information that is used for this table for you along with the Record for the POI Summary View. If you have your own specific transaction record and component, then enter that data here instead. You would do this if you wanted to capture additional information for the Type that isn’t in PER_POI_TRANS. Doing this does require customization, as you must create the record, the component, and the summary view. Record for POI Summary View If you chose PER_POI_TRANS as the transaction record, then this field will be set to POI_OTH_VW as this view can be used for any POI type that uses that transaction record. If you created your own POI transaction record though, you will need to also create this summary view as well. Person of Interest Checklist:

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 73

What checklist to default in on the PERSONAL_DATA component when this POI type is chosen. You can create your own checklist or use one that has already been set up. This field is not required.

Allow in Generic Add Component: Determines whether this POI type will be available in the dropdown list of types in the PERSONAL_DATA component. You should turn this on to allow your POI type to be selected. Allow in Generic Update Component: Determines whether this POI type will be maintainable in the PERS_POI_MAINTAIN component. You should turn this on to allow your POI type to be selected. Comment: Additional notes on the POI type.

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 74

Appendix B:

Job Action Table Values

Some actions have specific validation rules regarding when they are valid for a specific assignment as of the JOB.EFFDT being entered or modified. These actions are described in the table below.
Table of Actions and Status and the impact and validation rules Action Description Valid For Pay Status HR Status PER_ORG Valid for HR Status Valid for Pay Status

ADD Add Contingent Worker Active ADL Additional Job Active ASC ASG

Active Active

CWR only Inactive EMP, CWR or POI Inactive Employee Only Employee Only Active Inactive

Terminate Assignment Completion d Inactive Assignment Active Active

AWD Award - Monetary AWH Award - Non Monetary BNP BON Beginning of Notice Period Bonus Terminate d Inactive

EMP, CWR or POI Active EMP, CWR or POI Active EMP, CWR or POI Active EMP, CWR or POI Active CWR or POI Active EMP, CWR or POI Active EMP or CWR Active EMP, CWR or POI EMP, CWR or POI Active EMP, CWR or POI Active Active EMP, CWR or POI Employee Only Inactive EMP, CWR or POI Active EMP, CWR or POI EMP, CWR or POI Active Leave of Absence Active Suspended Active Paid Leave of Absence Active Leave of Active EMP, CWR or POI Active EMP, CWR or POI Active

COM Completion DEM Demotion DET DTA EDT EXT FSC HIR INT JED JRC LOA LOF Detail Data Change End of Detail Extension of NTE Date Family Status Change Hire Completion of Introductory Period Earnings Distribution Change Job Reclassification Leave of Absence Layoff Long Term Disability with Pay Long Term Disability

LTD LTO

EMP, CWR or POI Active EMP, CWR or POI Active

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 75

Table of Actions and Status and the impact and validation rules Action Description Valid For Pay Status HR Status PER_ORG Valid for HR Status Valid for Pay Status

Absence PAY Pay Rate Change Paid Leave of Absence Active Active Active EMP, CWR or POI

PLA POI POS PRB PRC PRE PRO PSF REC REH RET RFA

Paid Leave of Absence Add Person of Interest Position Change Probation Completion of Probation FPS Prehire Promotion Change of Pay System Recall from Suspension/Layoff Rehire Retirement Return from Temp Assignment

EMP, CWR or POI Active Person of Interest Only Inactive EMP, CWR or POI Active EMP, CWR or POI Active EMP, CWR or POI Active

Terminate d Inactive

Employee Only Inactive EMP, CWR or POI Active EMP, CWR or POI

Active Active Retired

Active Active Inactive

EMP, CWR or POI Employee Only Inactive EMP, CWR or POI EMP, CWR or POI

Suspended

RFD RFL

Return from Disability Return from Leave

Active Active

Active Active

EMP, CWR or POI EMP, CWR or POI Contingent Worker or POI Inactive EMP, CWR or POI EMP, CWR or POI Employee Only

Any Disability Leave Any Leave

RNW Renewal Return to Substantive Job RTS RWB RWP

Active Active Terminate d Inactive Active Inactive

Return from Work Break Active Retired with Pay Retirement with Pay Short Term Disability with Pay Short Term Disability Hold Substantive Job Retroactive Delete

Suspended Short Work Break

STD STO SUB SUP

Paid Leave of Absence Active Leave of Absence Active Suspended Active

EMP, CWR or POI Active EMP, CWR or POI Active EMP, CWR or POI Employee Only

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 76

Table of Actions and Status and the impact and validation rules Action Description Valid For Pay Status HR Status PER_ORG Valid for HR Status Valid for Pay Status

SUS

Suspension

Suspended Active Short Work Break

EMP, CWR or POI

SWB TAS TDL TER TWB TWP XFR

Short Work Break Temporary Assignment Active Terminate Detail Assignment Terminate d Termination Terminated with Benefits U Terminated with Pay Transfer U

Active Active

EMP, CWR or POI Active EMP, CWR or POI Active EMP, CWR or POI

Inactive Inactive Inactive

EMP, CWR or POI EMP, CWR or POI EMP, CWR or POI EMP, CWR or POI

Some actions will have an effect on the various dates that are associate with an assignment. The Termination, Assignment End Date and Last Date Worked will be set to the JOB.EFFDT less one day. The Hire, Latest Hire, Assignment Start, Latest Assignment Start will be set to the JOB.EFFDT.

Table of Actions that have an effect on the Assignment dates Set Hire Set Last Hire Set Term Set Last Set Asgn Asgn Set Asgn Start Start End Set Last Date Worked

Action Description

Add Contingent ADD Worker Yes ADL Additional Job Assignment ASC Completion ASG Assignment COM Completion HIR Hire Leave of LOA Absence LOF Layoff Long Term Disability with LTD Pay Long Term LTO Disability PLA Paid Leave of Yes

Yes

Clear Clear Yes Clear Yes

Yes Yes

Yes Yes

Clear Clear Yes Clear Yes Clear

Clear Clear

Yes
Clear Yes Clear Yes Yes

Yes Yes

Yes Yes

Yes

Clear

Yes

Yes

Yes Yes Yes

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 77

Table of Actions that have an effect on the Assignment dates Set Hire Set Last Hire Set Term Set Last Set Asgn Asgn Set Asgn Start Start End Set Last Date Worked

Action Description

POI PRE

Absence Add Person of Interest FPS Prehire

Yes

Yes

Clear Yes

Yes

Yes

Clear Yes

Clear Yes

Recall from Suspension/Layo REC ff REH Rehire RET Retirement Return from RFD Disability Return from RFL Leave RNW Renewal RTS Return to Substantive Job

Yes

Clear Clear Yes

Yes

Clear Clear Yes

Clear Clear Yes Clear Clear Clear Yes Clear

Yes

Clear Yes

Yes

Clear Yes

Return from RWB Work Break Retirement with RWP Pay Short Term Disability with STD Pay STO SUS Short Term Disability Suspension

Yes

Yes

Yes

Yes Yes Yes Yes Yes Yes Yes

Short Work SWB Break TER Termination Terminated with TWB Benefits Terminated with TWP Pay

Yes Yes Yes

Yes Yes Yes

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 78

Appendix C:

New Assignment Decision Matrix

Main Drawing

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 1

Handle Special Assignments

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 2

Is this an Additional Assignment?

August 2005

Understanding the Enterprise HCM Person Model in Release 8.9

Page 3

Sign up to vote on this title
UsefulNot useful