Wiki: PERSONNEL ACTION

PERSONNEL ACTIONS#

PA Overview#

Personnel Actions (PA) are date sensitive proposals to change a person's employment and/or work arrangement, for which some kind of approval is required. Organizations use the PA process to control and manage information changes. Changes may be created through a variety of sources and locations, supporting remote data entry from field locations, plants or other premises.

Changes may be pre-approved by the originator, approved centrally, or a combination of both methods may be used, depending on the organization's requirements.

Personnel actions may be in a pending, approved, updated or declined status. Only personnel actions that are approved will be updated to a person's employment or assignment records. Changes that are in a pending, updated or declined status are ignored.

PA Rules#

There are three flavors of implementations for Personnel Action tables:
- Single Instance
  - These tables will allow only one open PA against them.
  - Examples of these type are Identities, Elections, and Personals
- Transaction
  - These tables will force a PA to be created for every record that is inserted, updated, or deleted
  - An example of this is Contacts
- Transaction Child
  - These tables will always track PA’s against the parent table.
  - Examples of these are Contacts Types and Aliases
By default, only PA’s created in a specific form will only be visible in that form.
The PA Effective date can be changed at any time as long as it does not go beyond any applicable effective or expiry dates.
The PA Effective date will become the new effective date for any date sensitive changes that are made.
PA’s that are not approved can be cancelled or maintained by the person who created them.
Approvers are allowed to update the PA Effective Date of the record prior to approval/processing.
PA’s can only be permanently updated in the database once they are approved.
Approving a PA does not necessarily require the set up of Approval Processes.
A PA will not be processed when any discrepancies are found between the PA old values and the table's current values.

PA Life Cycle#

Creation#

When a form is changed and the form has an associated PA Type, all changes are automatically recorded in a Personnel Action.
When a PA is created, you are given the ability to set the PA Effective Date.
Only changed column and table context column values are stored on the PA.
You may add new changes (create a new PA) even if the current PA has been not been approved.

Updating#

Forms show all outstanding PA’s that have a PA Type matching their name
When a form is changed that contains an existing PA that is in the approval process, the date effective dialog prompts you to indicate the type of change.
When updates are done (with or without a date change), the original PA is cancelled and a new PA is created
If the date entered must be greater than the current PA effective date, a new PA is created

Personnel Action Set Up#

Personnel Action Types - ISPY #

In order to track changes made to employee’s information through a PA, a Personnel Action type must be created on the ISPY form. A separate Personnel Action type needs to be defined for each type of PA that may be created, for example a PA type for an address change and another PA Type for an assignment change. The PA type must be associated to the Change Reason and the database table in which the change is to take place on.

Once the database table has been selected, the ISPY form will populate the columns that are on that table. Any changes made to the columns listed here for this PA type will result in a PA being triggered.

Functions - IMFN #

The PA type that was established in the ISPY must be associated to the form that the PA change will be done on. This is done in the ISFPT form. If the Personnel Action type is not associated to a function on the ISFPT, the Personnel Action will not work.

NOTE: High Line does not guarentee that any custom form created can be adapted to use a PA.

PA Types should not be linked to forms that are not designed to specifically to handle PA's.

This would include:

Any Non-employee centric screens (ie the employee is not the focus of the screen)
Any form that has multiple instances of the same table in the form table usages (Multiple P2K_HR_ASSIGNMENT_DETAILS seperated by a different Alias).
Any admin form not set up as a PXXX function (Do not put a PA on the IEAS - Use the PEAS)

Where Clauses - IMDAO #

A “Where clause” must be created to link the PA type with an approval process. In IMDAO select the Data Source Name of P2K_SA_PERSONNEL_ACTIONS.

The “Where Clause” will have a type of ‘Ad Hoc’ and will reference the database column ‘SPY_ID.PA_TYPE_CODE”.

Under the Operator, select Equals and enter in the Value field the PA type that was established on ISPY.

This ‘where clause’ will be used as part of the Approval Process defined in the IDAP form.

Approval Setup - IDAP #

To establish an approval process for a PA, the IDAP form must be defined. The Approval Type must be 'Personnel Actions'.

The Approval Steps Seq # column determines the number of steps involved in the approval process. Under the Approval steps the Function Name must be the Pxxx form that the PA is being done on. The Where Clause created in IMDAO should be entered in the Where Clause field, which will link the PA type with this Approval Process.

The Approver tab specifies the people that are able to approve this PA type.

For more information on Approvals see the page Approvals.

Personnel Actions in Admin Versus Self Service#

It is important to realize that the functionality of PA's in Self Service differs significantly from that of Admin. In Self Service, an action by either the employee or the manager automatically triggers the creation of a PA if the form has a PA Type associated with it (on the function). A Where Clause may be used determine which approval process is followed for the PA.

Personnel Actions in Admin#

The Admin system uses ‘P’ type screens such as:

(This list may not be complete)

Unlike the Self Service solution, a PA must be initiated prior to changing any information.

Personnel Actions in Self Service#

When employees make changes through Self Service, PA’s are automatically generated if a PA Type is associated with the form they are using. The information captured in the PA’s is highlighted so the employees can easily see their changes.

Managers and Administrators use Self Service to approve PA’s. Once all of the required approvals are received, the PA Type changes are permanently updated in the database. The updating can occur on an individual basis or in mass.

Current PA Limitations in SS

The recording of PA’s is not fully supported in the Professional version. The setup and administration of PA’s can be done in Admin but the recording of PA’s in only supported in Self Service.
Possible Future Development - any PA with a table associated to that form should show in that form.
i.e. Changes made in Employee Promotions (WMEPR) should show in My Assignments (WEEAS)

The Self Service system uses screens such as:

WEEPP

Based on	P2K_HR_IDENTITIES, P2K_HR_PERSONALS
Create	Make a change in WEEPP
Update	Mark current PA as Cancelled and add new PA with current details
Delete	Mark PA as Cancelled

WEBEL

Based on	P2K_BE_ELECTIONS
Create	Enter a transaction in WEBEL
Update	Mark current PA as Cancelled and add new PA with current details
Delete	Mark PA as Cancelled

WEECN

Based on	P2K_HR_CONTACTS, P2K_HR_CONTACT_ROLES
Create	Enter a Contact in WEECN
Update	Mark PA as Cancelled and add new PA with current details, this included changes/additions to Contact Roles
Delete	Mark PA as Cancelled

WEBDP

Based on	P2K_HR_CONTACTS
Create	Enter a Dependent in WEBDP
Update	Mark current PA as Cancelled and add new PA with current details
Delete	Mark PA as Cancelled

WMEPR

Based on	P2K_HR_ASSIGNMENT_DETAILS
Create	Make a change in WMEPR
Update	Mark current PA as Cancelled and add new PA with current details
Delete	Mark PA as Cancelled

WMETR

Based on	P2K_HR_EMPLOYMENTS, P2K_HR_ASSIGNMENTS, P2K_HR_ASSIGNMENT_DETAILS
Create	Make a change in WMETR
Update	Mark current PA as Cancelled and add new PA with current details
Delete	Mark PA as Cancelled

Processing PA’s#

Processing PA's in Admin#

Personnel Actions will be created and maintained using the Pxxx forms.

When you first come into the Pxxx form and if there is no PA waiting to be processed, the Initiate PA button will be available. You will note that at the bottom of the form the Process PA button will be unavailable to select. By pressing the Initiate PA button, the Create Personnel Action dialog box will appear requesting initial information for the PA. This dialog box will have the PA (Request)#, Takes Effect date, Change Reason and Description. The Change Reason and Description fields will be defaulted to the ISPY values.

Select the date in which the change is to take place. The PA (Request) will populate using code sequencing established on IMCS. Once ‘OK’ has been selected, the user may now make the necessary changes for the PA. Once changes are made, press the save icon and the fields that have been changed will be highlighted in bold. Once the changes are completed and saved, the user must press the Submit PA button so the PA may be submitted for approval. Once submitted an approval bar will appear at the bottom of the form.

The status of the PA can be viewed on ISPA once it has been created on Pxxx. This is also the record of past Personnel Actions that have occurred.

A PA can have the following statuses;

In Progress	The PA has been created and is awaiting approval
Approved	The PA has been approved and is waiting to be processed
Not Approved	The PA has not been approved. If a PA is not approved the original values will revert back into the fields changed.
Completed	The PA has been created, approved and processed. The changes made are now permanently in the system.

Administrators may run the RSPA report to review Personnel Action requests.

Once the PA is approved, the Process PA button can be selected in the Pxxx or ISPA form to process on an individual basis or in mass through the USPPA batch process.

USPA is required to be run for any back-end type PA’s such as USEP, USMC, etc.
USPPA is required for all Java created PA’s through forms such as ISPA, SS forms, etc.

Once the Process PA button has been selected, the user will get the message “Personnel Action 1234 processed successfully”.

This will finish processing the PA and will make the following changes.

The fields on the form (ie: IEAS) will be updated and they will no longer appear bold on the Pxxx (ie:PEAS) form.
The PA on ISPA will be updated from “Approved” to “Completed”.
ISPA will keep the record of changes that have occurred. Each PA effective date will be maintained on this form.

Processing PA's in Self Service#

There are a variety of forms that Managers, Administrators and Approvers may use to process personnel actions.

Process Personnel Actions: Administrators can use the WADAR form to view and approve active PA’s.

View Personnel Actions History: Administrators can use the WADARH form to view PA history.

Review Personnel Actions: Managers can use the WMDAR form to view and approve active PA’s.

Approve Personnel Actions: Managers, Administrators and Approvers can use the WVDAR form to view and approve active PA’s.

Example PA Process#

The following example is for a scenario where you have a business requirement that states that employees do their own benefit elections which then need to be approved by the employee's manager.

Below is an example of a basic PA process that carries out this business function. It shows the setup required and the resulting functionality in Employee Self Service (ESS) and Manager Self Service (MSS).

Set Up #

IMDAO - Define Where Clauses by Table

Where Clauses may need to be set up to properly qualify people for benefit election approvals if the approval logic is complicated. To create Where Clauses, users must have the WWW_ADMIN role with execution rights for IMDAO -Where Clauses by Table or IMWC-Where Clauses.

Choose the table P2K_SA_PERSONNEL_ACTIONS in IMDAO.
The Where Clause should be named and described by the user.
The Where Clause usage must always be “User Defined”.
The Where Clause type must always be “AD HOC”.
One of the columns selected should be SPY_ID.PA_TYPE_CODE in order to specify that the Where Clause is applicable for the “Benefit Election” PA Type. Changes made on the WEBEL table by an employee will trigger a “Benefit Election” PA Type.
Create the parameters of the Where Clause as needed using the available operators.
Test the completed Where Clause right on the IMDAO form.

IDAP - Define Approval Processes

The benefit election approval process may be defined as follows:

Approval Processes are defined on IDAP.
The Approval Process should be named and described by the user.
The Approval Type for benefit elections must be “Personnel Action”.
The Priority indicates the sequence in which the PA will be executed when multiple approval rules exist with the same type. The highest priority Approval Process is executed first.
Approval steps must be defined for each Approval Process. This section indicates the total number of steps to be completed before the PA is completely approved and ready for permanent update.
The Approvers section allows the user to define specific managers, people, or people lists that have the authority to approve the PA.
In our example we will use the Assignment Manager.

Functionality

Employees use Employee Self Service to enter their benefit elections. Managers use Manager Self Service to view and approve the benefit elections for their employees. Other Administrators use HR Self Service to view and approve the benefit elections of the employees they are authorized for. Below is a sample process flow:

Employee 6142 wants to change their benefit coverage.
Employee 6142 logs into Employee Self Service and goes to My Current Benefits (WEBEL).
Employee 6142 declines the optional coverage of DENTAL BCF. When the PA is created, the following message is displayed:

“Any field emphasized as burnt orange is currently being reviewed for approval in Personnel Action #1853”

Employee 6142's manager logs into Manager Self Service and goes to Approve Change Requests (WVDAR).
The details and purpose of the outstanding PA’s are presented for review by the Manager.
The manager is able to approve or decline the request.
The Process PA's button becomes active when all of the approval steps are completed. Clicking this button applies the change permanently in the database. Alternatively, approved PA’s could also be batched and updated in mass through the USPPA function.

Personnel Action FAQ's#

The page Personnel Action FAQ's contains a list of Frequently Asked Questions regarding Personnel Actions.

Notes #

Click to create a new notes page

Table of Contents