To

Understanding and Using Life Event Checklists in

Bottom
Oracle HRMS R12 (Doc ID 740618.1)

In this Document

Abstrac
t

Histor
y

Detail
s

Set Up
Steps

Managing Checkli
sts

Set up Performers in
AME

Background
Processing

Allocating Checklist Tasks

using an API

Using Allocated Checklists Window in the Professional User

Interface (PUI)

Accessing Ex-Employees in the Allocated Checklists

window

Troubleshooti
ng

Reference
s

Applies to:

Oracle Human Resources - Version 11.0.0 and later

Information in this document applies to any platform.

Abstract

This document provides a technical and functional appreciation of the Life

Event Driven Checklist functionality available from Release 12 of Oracle
HRMS, to be differentiated from the checklist items that can be configured
in People Management templates (see Note:744150.1). It includes a step
by step approach to the setup, and seeks to explain what is happening in
the background to further the reader's understanding of the process.

History

Author : Steve Cooper

Create Date 01-Oct-2008
Update Date 09-Sep-2014
Expire Date

Details

Introduction

In the field of Human Resource Management certain events that happen

during the lifetime of a person on the system will require that a set of
tasks are actioned as a result. Such events might include Hiring an
Employee, Termination, or Transfer, each of which would have an
associated 'to do' list. Consider the following:

Event Checklist Tasks

Hire Adminstration Create Internal username/passwords

Order IT equipment

Allocate mentor

Mentoring Plan Introduce to colleagues

Induction Training (itemise)

Specialist Product Training (itemise)

Termination Redundancy Job Counselling

Initiate notice period

Disable username/passwords

The Checklist and tasks would be allocated to an employee after the

triggering of a Life Event. Performers can be assigned automatically or
manually to each task, which can be monitored by manager and employee
for progress.

These Checklists need to be differentiated from the existing checklist

functionality which is used to monitor sign-off items in People
Management (See Note:744150.1).

Set Up Steps

The allocation of tasks to an employee is dependent on two things

 The triggering of a Life Event that has been associated with the
Checklist

 The eligibility profile assigned to an individual task.

A Life Event must be defined and linked to a Checklist, and Oracle

Advanced Benefits (OAB) must be installed in order to create a
Life Event with Defined Person Changes. So a full install of OAB is
a mandatory prerequisite to using Life Event Checklists.

Furthermore, Checklists are limited to Employee person types as

OAB does not process Life Events for Contingent Workers or
Applicants, neither does the Eligibility Profile pick up those
person types.

1. Create Checklist Life Event

General Definitions -> Additional Setup -> Life Event Reasons

Form Name - BENLEVRS ; Function Name - BENLEVRS

Create a new Life Event with the type of Checklist, and click on Person
Changes button. If there is an existing person change defined that you can
use, choose it from the LOV on Name, otherwise click on Define Person
Change to specify the event that will trigger the allocation of your
checklist tasks. For example, the following will detect that a New
Employee has been entered by establishing if a new period of service has
been created:

Table Name - PER_PERIODS_OF_SERVICE

Column Name - DATE_START

Old Value - No Value

New Value - Any Value

2. Create Eligibility Profile (Optional)

By Defining Eligibility Profiles you can tailor the tasks in a checklist to suit
particular groupings. For instance, some tasks may only be applicable to
people in a particular location. Others to people in a particular
organization. If no eligibility profile is defined then all people are eligible
once the Life Event is processed. The Eligibility Profiles form used must be
the one available under the Work Structures -> Checklists menu as the
'Applies To' field defaults to a Checklist Profile, as opposed to a Benefits
Profile.

Navigate to Work Structures > Checklists -> Eligibility Profiles

Form Name - BENELPRO ; Function Name - BENELPRO_CHECKLIST

For example, to create an eligibility profile that is only applicable to

employee assignments in a particular location:

Header

Name - London Employees

Assignment Type - Employee Assignment Only

Applies To - Checklist Profile

Status - Active

Employment Tab

Work Location from dropdown menu

Seq -1

Work Location - London

3. Create Additional Checklist Categories (Optional)

There are two seeded checklist categories,

 On-Boarding (recruitment, hiring, orientation,etc)

 Off-Boarding (termination, relocation, long term sickness,etc)

Additional categories can be created by extending the lookup type,CHECK

LIST_CATEGORY.

Navigate to Other -> Application Utilities Lookups

4. Create Descriptive Flexfields (Optional)

There are two Descriptive Flexfields which can be used to provide
additional context information on Allocated Checklists and Tasks if
required.

 Additional Allocated Checklist Details - Base

table(PER_ALLOCATED_CHECKLISTS. You could set up this DFF to
display segments specific to the defined Checklist.

 Additional Allocated Task Details - Base

table(PER_ALLOCATED_TASKS).
You could set up this DFF to display segments specific to the defined
tasks

5. Create Checklists and Tasks

The Checklists and Tasks are defined in the Setup/Maintain Checklists

function.

Navigate to Work Structures > Checklists -> Setup/Maintain Checklists

Use Add Checklist to create a checklist against a specific category. Define

a name and link in the Life Event created in step 1)

Then use Add Task to create tasks associated to your checklist. Define a
name, duration and mandatory flag. Link in an eligibility profile if required
(see step 2), and an AME identifier if a performer is to be assigned
automatically to the task when it is allocated (see below for further
information on setting up AME). Alternatively a performer can be allocated
manually in the Allocated Checklists function in Self Service.

6. Run Allocate Checklists and Tasks Program

This program should be scheduled at intervals regular enough to cater for

the frequency of occurring Life Events. When the Allocated Checklists
function is run in Self Service the program is run in background for the
individual person to ensure the information displayed is current ,but it's
better to remove the overhead by scheduling this concurent program.

The program identifies pending Life Events linked to Checklists, and

allocates the checklist tasks to the person based on eligibility profiles.

Navigate to Processes and Reports - > Submit Processes and Reports.

N.B. The program must have first been added to the reports Request Set.

Program Name - Allocate Checklists and Tasks Process (executes

pl/sql procedure per_checklist_events.allocate_tasks)

Managing Checklists

Managers can view and update the tasks allocated to the employees
reporting to them, and employees can view, and update their own
allocated tasks. For employees, add the function
HR_ALLOCATED_CHECKLIST_SS to their Self Service menu if not already
there, and for Managers, the function is
HR_ALLOCATED_CHECKLIST_MGR_SS to get access to the Allocated
Checklists page.

The attributes of the tasks can be maintained here, including completion

status, duration ,performer and flexfield information. Tasks can also be
deleted, and added to the employee.

The checklist and tasks are allocated by the Allocate Checklists and Tasks
Process. It should be noted, however, that subsequent changes to the
checklist are not re-allocated to employees who have already received the
checklist and tasks when the Life Event is triggered. If a task has been
added since the allocation, the task can be added manually to each
employee using the Allocated Checklists page, or by running
the per_checklist_events.allocate_person_tasks procedure
(See Allocating Checklist Tasks using an API section).

Set up Performers in AME

Performers can be automatically assigned to designated checklist tasks by

setting up an Approval Group within Oracle Approvals Management (AME).
This section will provide some basic steps on how to do this, but for a
more detailed understanding of using AME and Workflow Notifications, see
the Oracle Approvals Management Implementation Guide, and Oracle
Workflow Administrator and Users Guides.

1. Assign Roles and Grants

Before attempting to set up AME, checklist approval requirements must be

well-planned in advance, and the user with the responsibility for setting
this up should be assigned the AME Roles and grants. Follow instructions
in Note 375119.1. AME has implemented Role Based Access Model
(RBAC), so do not attempt to assign the AME Responsibilities directly to
your user as you will not be able to select any transaction types using the
AME Dashboards as a consequence.

2. Create Conditions, Approval Group and Rule

 From Business Analyst Dashboard, select CHECKLIST transaction

type

 Click on Conditions link, and click on Create button. Select

 CHECKLIST_ATTRIBUTE and enter a name in the 'String Value' field in
the region below. This will be the Approvals Identifier for linking to
the checklist task. See step 5 in Setup Steps above.

 Create Approval Group by selecting the tab 'Approver Groups'. Set

usage type to Static, and voting method to 'First Responder wins',
and add group members as required.

 Associate the Action Type, 'Approval-Group Chain of Authority' to the

CHECKLIST Transaction Type.

 Select 'Rules' tab to define an AME Approval Rule of type 'List

Creation', and associate with your condition and action type.

 Finish the process to save the AME rule.

3. Update Checklist Task

In Setup/Maintain Checklists under Work Structures -> Checklists menu,

update each required task with the Approvals Identifier. This sets the
column AME_ATTRIBUTE_IDENTIFIER on the
table PER_TASKS_IN_CHECKLIST to the AME condition you have created.
If different performers required for each task, more than one condition
may be required.

4. Respond to Notifications

When set up, the performer will default against the allocated tasks. A
notification will be sent to each member of the Approval Group
saying,'Action Required: Complete <task name> for <employee
name>', and include two buttons, COMPLETED and NOT COMPLETED.
Whichever person responds to these buttons first will set the status on the
task to either Completed or Rejected. The Notification to all performers
will then show 'FYI: <employee name> task <task name> is
updated'

Please note that Checklists use the parallel approval process which means
that on initial allocation the first approver in the list is selected for display
in the 'Allocate Tasks' page.

Background Processing

1) Life Events

Checklist Life Events can be queried using the following statement

select LER_ID,

EFFECTIVE_START_DATE,
 EFFECTIVE_END_DATE,

NAME,

BUSINESS_GROUP_ID,

TYP_CD

from BEN_LER_F

where typ_cd='CHECKLIST';

For Example

LER_ID EFFECTIVE_START EFFECTIVE_END NAME BG

TYPE

------ --------------- ------------- -------------------- -- --------

41775 01-JAN-08 31-DEC-12 New Hire (Checklist) 7269

CHECKLIST

2) Checklists

Example query of Checklist definition :

col name format a30 col checklist_category format a10

select CHECKLIST_ID,

NAME,

CHECKLIST_CATEGORY,

EVENT_REASON_ID

from PER_CHECKLISTS

where BUSINESS_GROUP_ID=7269;

Example Without Life Event Reason linked

CHECKLIST_ID NAME CATEGORY

EVENT_REASON_ID
------------------ ------- -------------- ------------------------
61 Mentoring Period (UK) ONBOARD

Example With Life Event Reason linked

CHECKLIST_ID NAME CATEGORY

EVENT_REASON_ID
------------------ ------- -------------- -------------------------
61 Mentoring Period (UK) ONBOARD 41775

3) Checklist Tasks

Example query of individual tasks:

col checklist_task_name format a30 col mandatory_flag a1 col

target_duration_uom format a1

select TASK_IN_CHECKLIST_ID,

CHECKLIST_TASK_NAME,

ELIGIBILITY_PROFILE_ID,

MANDATORY_FLAG,

TARGET_DURATION,

TARGET_DURATION_UOM,

TASK_SEQUENCE

from PER_TASKS_IN_CHECKLIST

where CHECKLIST_ID=61;

TASK_IN_CHECKLIST_ID CHECKLIST_TASK_NAME
ELIG_PROF_ID M DURATION UOM

-------------------- ------------------------------ ------------ - -------- ---

81 EDP New Hire Plans 20433 Y 1W

82 HRMS Troubleshooting Sessions 20433 Y 2

D

62 Orientation 20433 Y 1W

4) Processing a Life Event

The Benefits model has been adapted so that whenever a Checklist Life
Event is triggered, the following procedure is called by the
ben_create_ptnl_ler_for_per (bencrler.pkb) package:

PER_CHECKLIST_EVENTS.CREATE_EVENT
(p_effective_date => p_effective_date
,p_person_id => p_person_id
,p_assignment_id => p_assignment_id
,p_ler_id => p_ler_id
);
This creates a row in the table PER_BEN_IDENTIFIED_EVENTS.

For example

select

BEN_IDENTIFIED_EVENT_ID,

EVENT_REASON_ID,

PERSON_ID,

STATUS,

EFFECTIVE_DATE

from PER_BEN_IDENTIFIED_EVENTS;

BEN_IDENTIFIED_EVENT_ID EVENT_REASON_ID PERSON_ID STATUS

EFFECTIVE_DATE

----------------------- --------------- ---------- ------ --------------

61 41775 29722 Pending 22-SEP-08

This row is the driver for allocating tasks to employees.

5) Allocating Tasks to Employees

The concurrent program, Allocate Checklists and Tasks, runs the procedure
per_checklist_events.allocate_tasks. This checks for rows on
PER_BEN_IDENTIFIED_EVENTS with a status of Pending. If it finds any, it
will create rows on the two tables PER_ALLOCATED_CHECKLISTS and
PER_ALLOCATED_TASKS.

col checklist_name format a30

col checklist_category format a10

select ALLOCATED_CHECKLIST_ID,

CHECKLIST_ID,

PERSON_ID,

ASSIGNMENT_ID,

CHECKLIST_NAME,

CHECKLIST_CATEGORY

from PER_ALLOCATED_CHECKLISTS

where CHECKLIST_ID=61

ALLOCATED_CHECKLIST_ID CHECKLIST_ID PERSON_ID CHECKLIST_

NAME CATEGORY

---------------------- ------------ ---------- -------------- --------

21 61 29722 Mentoring Period (UK) ONBOAR

D

select ALLOCATED_TASK_ID,

ALLOCATED_CHECKLIST_ID,

TASK_NAME,

PERFORMER_ORIG_SYS_ID PERFORMER,

TASK_OWNER_PERSON_ID TASK_OWNER

from PER_ALLOCATED_TASKS

where ALLOCATED_CHECKLIST_ID = 21;

ALLOCATED_TASK_ID ALLOCATED_CHECKLIST_ID TASK_NAME

PERFORMER TASK_OWNER

----------------- ---------------------- -------------------- --------- ---------

-

21 21 Orientation 29498 2765

5

22 21 New Hire Program

23 21 HRMS Troubleshooting Sessions

The table PER_BEN_IDENTIFIED_EVENTS has status changed to

Processed.

BEN_IDENTIFIED_EVENT_ID EVENT_REASON_ID PERSON_ID STATUS

EFFECTIVE_DATE

----------------------- --------------- ---------- ------ --------------

61 41775 29722 Processed 22-SEP-08

Allocating Checklist Tasks using an API

When setting up checklists, it may be necessary to do a

manual allocation because some employees have already experienced the
Life Event that has been defined. For instance, if the Life Event is
triggered for new employees, and several were entered onto the system
prior to the Life Event being defined and linked to the Checklist. In these
circumstances the per_checklist_events.create_event procedure can be
called directly. The example shown passes the parameters directly but it
can be incorporated into a loop where the target person_ids are passed in
with the target start dates.

DECLARE

v_error varchar2(4000);

l_target_start_date date := to_date('01-Oct-2008','dd-mon-yyyy');

l_person_id number := 31524;

l_life_event_id number := 41775;

BEGIN

dbms_output.ENABLE(1000000);

per_checklist_events.create_event

(p_effective_date => l_target_start_date

,p_person_id => l_person_id

,p_assignment_id => null

,p_ler_id => l_life_event_id);

EXCEPTION

WHEN OTHERS THEN

v_error := SUBSTR(SQLERRM,1,250);

dbms_output.put_line(v_error);

END;

commit;

This has the effect of creating the Pending row on

PER_BEN_IDENTIFIED_EVENTS. Once that is present it will be picked up by
the Allocate Checklists and Tasks concurrent program. This concurrent
program can also be called directly. For example

DECLARE

l_errbuf varchar2(2000);

l_retcode varchar2(1000);

BEGIN
per_checklist_events.allocate_tasks

(errbuf => l_errbuf,

retcode => l_retcode,

p_purge => 'Y');

END;

commit;

If a Checklist had not been previously allocated, the allocate_tasks

process should be run. Howvever if a task has been added to an existing
checklist after allocation to a group of employees, the additional task can
be added either manually in the Allocated Checklists page, or by the
allocate_person_tasks procedure as described below. A Pending row must
have previously been written to the per_ben_identified_events table using
the create_event procedure.

DECLARE v_error varchar2(4000); l_person_id number := 29622; BEGIN

dbms_output.ENABLE(1000000); per_checklist_events.allocate_perso
n_tasks (p_person_id => l_person_id); EXCEPTION WHEN OTHERS THEN
v_error := SUBSTR(SQLERRM,1,250); dbms_output.put_line(v_error); END;

Using Allocated Checklists Window in the Professional User

Interface (PUI)

You can call the Allocated Checklists window from the Enter and Maintain
Person form (PERWSHRG) by adding the following function to your
Navigator menu:

HRALLCKL_PER_TF - Allocated Checklist (Task Flow)

Then add the HRALLCKL_PER_TF node to you person taskflow, and then as
a Navigation Option under the NPERSON node.

Accessing Ex-Employees in the Allocated Checklists window

You can view Ex-Employees using the Allocated Checklists window in the
PUI, and in Self Service by setting the &pEnableTerms=Y parameter on the
following functions:

HR_ALLOCATED_CHECKLIST_MGR_SS - Manager Self Service

HR_ALLOC_CHECKLIST_ADV_SRCH_SS - HR Professional 4.0

Troubleshooting

The likeliest problem to occur with Checklists would be a failure in the

allocation process.

1) Check to see if the Life Event was processed for the individual by
examining if a row was created on per_ben_identified_events. Note that
the rows are cleared if the purge parameter is set to Yes when running the
Allocate program, so it's a good idea not to purge initially. If there is a row
there either Pending or Processed the problem wouldn't be with the Life
Event.

If a row is not created, the event defined in Person Changes on the Life
Event is not happening. Checking an individual's data using EBS Human
Capital Management (HCM) Person Analyzer (Note:1675487.1) may help
to understand why. For example, a common misunderstanding is to set up
a Life Event for Terminations, and to check for a change in Assignment
Status. Most of the time the status doesn't change when an assignment is
terminated. The record is merely end-dated.

2) Another possibility for a failure with the allocation process would be

that the eligibility profile is excluding the person. Check the profile
eligibility criteria matches the employee's criteria.

3) If the problem is not obvious, then a PYUPIP trace can be run to try and
identify the problem. Ensure there is a Pending row on
per_ben_identified_events for processing:

Open two sessions on the server.

Session 1

in sqlplus apps/apps

SQL> select userenv('sessionid') from dual;

Session 2

cd $PAY_TOP/bin

PYUPIP apps/apps <sessionid> > file.dmp

where : apps/apps is the login and password for the APPS schema.
<sessionid> is the value returned from Session 1.

Session 1

exec hr_utility.trace_on;
DECLARE

l_errbuf varchar2(2000);

l_retcode varchar2(1000);

BEGIN

per_checklist_events.allocate_tasks

(errbuf => l_errbuf,

retcode => l_retcode,

p_purge => 'Y');

END;

exec hr_utility.trace_off;

You will need to ctrl/c the PYUPIP session and then analyze

the trace statements written to file.dmp

Still Have Questions?