[{TableOfContents }]
!!!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|PA_TYPE_CODE] must be created on the [ISPY] form. A separate [Personnel Action type|PA_TYPE_CODE] 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|CHANGE_CODE] 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|PA_TYPE_CODE] is not associated to a function on the [ISFPT], the Personnel Action will not work.
%%information
__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 ||IMFDH] (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|DATA_SOURCE_NAME] of [P2K_SA_PERSONNEL_ACTIONS].
The “Where Clause” will have a [type|CONDITION_TYPE] of ‘Ad Hoc’ and will reference the database [column|COLUMN_NAME_LK] ‘SPY_ID.PA_TYPE_CODE”.
Under the [Operator|COMPARISON_OPERATOR], select Equals and enter in the [Value|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 |APPROVAL_TYPE] must be 'Personnel Actions'.
The Approval Steps [Seq #|SEQUENCE] column determines the number of steps involved in the approval process. Under the Approval steps the [Function Name|FUNCTION_NAME] must be the Pxxx form that the PA is being done on. The [Where Clause|WHERE_CLAUSE_CODE] 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|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:
%%columns
*[PEAL]
*[PEAS]
*[PECL]
*[PECMP]
*[PECT]
*[PEEI]
*[PEID]
*[PEMT]
*[PEPI]
----
*[PEPP]
*[PEPR]
*[PEST]
*[PESTT]
*[PETR]
*[PPPM]
*[PPRLC]
*[PPRLU]
*[PPRLUS]
/%
(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|PA_TYPE_CODE] 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|ACT_INITIATE_PA] button will be available. You will note that at the bottom of the form the [Process PA|ACT_PROCESS_PA] button will be unavailable to select.
By pressing the Initiate PA button, the [Create Personnel Action|MSCPA] dialog box will appear requesting initial information for the PA. This dialog box will have the [PA (Request)#|PA_NUMBER], [Takes Effect date|PA_EFFECTIVE_DATE], [Change Reason|CHANGE_CODE] and [Description|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|ACT_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|ACT_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.
%%information 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|ACT_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|MODULE-ESS]) and Manager Self Service ([MSS|MODULE-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|FAQ-PA] contains a list of Frequently Asked Questions regarding Personnel Actions.
----
![Notes|Edit:Internal.PERSONNEL+ACTION]
[{InsertPage page='Internal.PERSONNEL+ACTION' default='Click to create a new notes page'}]