Person Model HCM

 

Person Model in PeopleSoft HCM

Person model in PeopleSoft is nothing but a way of organizing and storing person related demographic and organizational information in the PeopleSoft database.

There are three type of person (Organisational relationship) in PeopleSoft

1. Employee (PER_ORG=EMP) – A person who is hired to provide services to the organization and has a legal employee relationship with the organization.
2. Contigent Worker (PER_ORG=CWR)- A person who provides services to the organization and who does not have a legal employee relationship with the organization.
3. Person of Interest (PER_ORG=POI) – A person who is neither an employee nor contingent worker but is of interest to the organization like external trainer, intern, pension payee etc. POI can be with or without job data.

When we add a person in HCM we capture two types of information about the person

1. Biographical data- Name, address, contact, national id,marital status etc
2. Organizational data-Job, Benefit program participation, earning distribution, Employment…etc.

When a person is added to organization (Navigation–Main -> Workforce Administration -> Personal Information -> Biographical -> Add a Person) , Biographical data is stored in below tables

Subsequently when organizational relationship is created for the same person  (Navigations : Main -> Workforce Administration -> Job Information -> Add Employment Instance,  Main -> Workforce Administration -> Job Information -> Add Contingent Worker Instance,  Main -> Workforce Administration -> Job Information -> Add POI Instance ) , Organization data is stored in below tables

Advertisement

To understand the person model and how organizational data is stored in database we need to understand terms like

·         Organizational Relationship (PER_ORG)

·         Organizational Instance (ORG_INSTANCE_ERN)

·         Job Assignment or Employment Record  (EMPL_RCD)

For this let us consider an example,

Consider an employee named “Aditya” is hired by XYZ technologies on 1 Jan 2017 , for this a HR user creates a JOB record for Aditya through the component “Add

Employment Instance” (Navigations: Main > Workforce Administration > Personal Information > Organizational Relationships > Add Employment Instance, Main > Workforce Administration > Job Information > Add Employment Instance) with the ACTION/ACTION_REASON = “HIR/HIR”

After this  hire is done if we check the three tables PS_PER_ORG_INST, PS_PER_ORG_ASGN and PS_JOB,

1. A new row with PER_ORG=EMP (indicating employee relationship) and  ORG_INSTANCE_ERN=0 has been created in PS_PER_ORG_INST and PS_PER_ORG_ASSGN tables.
2. EMPL_RCD field in PS_PER_ORG_ASSGN is also set to 0 as this is the first assignment.
3. A new row is added in PS_JOB with EMPL_RCD=0 and action as HIR.

Now say after few month from 1 April 2017 “Aditya” is assigned a additional responsibility of training new hires and he has to allocate 30% of his time for the same for one month. For this the HR user add a new effective dated row on job data with action/action reason say “POS/UPD” and changes the std hours in primary job and then creates a new job record through the component “Add Additional Assignment” (Navigation:Main > Workforce Administration > Job Information > Add Additional Assignment)

Since this is only additional assignment and employee’s organizational relationship is not changed

1. ORG_INSTANCE_ERN remains 0 and no new row is added in PS_PER_ORG_INST table.
2. A new record with EMPL_RCD =1 is added in PS_PER_ORG_ASSGN table.
3. Two new rows one to update std hours for EMPL_RCD=0 and action/action reason=”POS/UPD” and another with EMPL_RCD=1 for the new assignment is added in PS_JOB

Consider another scenario after few months “Aditya’ is loaned to other department as contigent worker from 1 Nov 2017.The HR user creates a contingent worker instance for him through the component “Add Contingent worker Instance” (Navigation: Main > Workforce Administration > Personal Information > Organizational Relationships > Add Contingent worker Instance, Main > Workforce Administration > Job Information > Add Contingent worker Instance)

1. A new row with a new ORG_INSTANCE_ERN=2 and PER_ORG=”CWR” is added to both PS_PER_ORG_INST and PS_PER_ORG_ASSGN tables.
2. EMPL_RCD field in PS_PER_ORG_ASSGN is also incremented and set to 2 in new row to indicate new assignment.
3. A new row is added in PS_JOB, with new EMPL_RCD=2, PER_ORG=”CWR” and ACTION as “ADD”.

To summarize,

The record, PS_PER_ORG_INST holds the organizational instances for a person and its represented by the field ORG_INSTANCE_ERN.
The record, PS_PER_ORG_ASGN holds the assignments under a particular organizational instance for a person.
The record, PS_JOB holds the details on each assignment and day to day transactions done on that assignment for a person.

Search Record

• The search record builds the search page for the component.
• The search record builds the search query, which retrieves the component data and populates level 0 for every page in the component.
• The search record builds the recent search results page for persistent searches.
• The search record defines the service parameters that must be mapped for related content service definition of the PeopleSoft Component URL type.

When you click a content reference to access a component, the system examines the search record and dynamically builds the search page based on the search key, alternate search key, and list box item properties of the search record. If you designate fields as search keys or alternate search keys, then those fields appear on the search page. When the user enters values in the search fields and clicks the Search button, the system incorporates those values into the WHERE clause of the search query. If the values provided by the user uniquely identify one row of data, then the system proceeds directly to the main page with the available information. Otherwise, the query retrieves the rows that match the criteria and displays the rows in a list box at the bottom of the search page. If you define fields as list box items on the search record, the system displays those fields as columns grid in the result set.

When you select a row from the list box, the runtime system generates a second query to fill the level 0 row in the component. The runtime system examines the level 0 record for the component and checks its key fields. It tries to retrieve level 0 key field values from the fields in the list box and uses those values in the WHERE clause used to populate the level 0 record.

The search record for a component might differ from the level 0 record definition for a component and might contain any number of search keys and list box items, but it must contain all of the key fields that are in the level 0 record for a component.

You might want to reuse a component, changing only its search record.

You can accomplish this by overriding the component search record at the time that the component is invoked from a menu. To override a component search record, specify a different search record in the properties of the menu item that invokes the component. The component uses the override search record when it is invoked from that specific menu item; the search record set in the component properties remains unchanged.

By reusing components in this way, you can limit redundancy, keeping your application smaller and easier to maintain.

https://docs.oracle.com/cd/E55243_01/pt854pbr0/eng/pt/tapd/task_UsingSearchRecords-0774ae.html#topofpage

PeopleSoft Search Record

• 0
  inShare

Posted by Rakesh Subhagan in PeopleTools | 4 Comments

A search record is a very import part of the component processing. In this post, I will tell you what its relevance is and how making changes to a search record can affect the search page.

Every Component in PeopleSoft should have a search record associated with it. Without specifying one, App Designer wouldn’t let you save the Component definition. We specify the search record in the properties of a Component as shown below.

On the search page for the component, a user may enter values against one or more or even none (leave all fields blank) of search key to retrieve the data. The Component Processor then performs a search against the search record to retrieve data from the database that matches the user’s input and populates the Component buffer during the Component build.

In short, this record provides the only values the user may choose to see. As such, it’s very much used in row level security as well.

Search Page

You can use the search keys and alternate search keys to retrieve values on the advanced search page. The basic search page allows you to use only one search criteria at a time – this can either be a search key or an alternate search key. On the Component Properties, you can specify what search page – basic or advanced – that a user would see by default.

If the list box item check box for a filed is selected, the values of that field are listed in the list box as shown below.

Bypass the Search Page

Sometimes it may be necessary to bypass the Search page. To do this, you can use a search record that doesn’t have any search keys. On finding that that there are no search keys selected, PeopleSoft will not show you the search page while accessing the component.

Since the delivered INSTALLATION record doesn’t have a search key, it’s common to see it being used in cases where the search page is not required.

Row Level Security

By adding fields like OPRID, OPRCLASS or ROWSECCLASS as a key to a search record, you can implemented row level security. When the Component Processor finds such a key in a search record, it would include a condition (over and above the user’s search criteria) which equates it to the user’s value (see below) there by limiting what data the user is able to see.

OPRID is equated to the user’s Operator ID.
OPRCLASS is equated to the Primary Permission List.
ROWSECCLASS is equated to the users Row Security Permission List.