[{TableOfContents }]
\\
The Approval Process definitions identify which transactions require approvals, the authorized approvers and the levels of approval required. The Approval process begins as soon as an employee (or other person) "submits" a transaction.
Approvals may be done in [{$applicationname}] or Self Service, by managers and/or administrators. Supervisors who log into the Manager Self-Service module can view and approve transactions initiated by their employees. Administrators who log into [{$applicationname}] or HR Self Service can view and approve transactions initiated by the employees they are authorized for.
!!What Can Be Approved?
||Applicant Hires| Approval of new hires is done on [IRAP], [IRCA] and [IRPO].
||Assessments| Approval of assessments is done on [IRSA].
||Benefit Elections| Approval of benefits selected on the [{$applicationname}] or Self Service election forms is done on [IBEL] or WxDAR.
||Class Registrations| Approval of class registrations for employees is done on [ICRSE] or WxCAT.
||Class Schedules| Approval of class schedules is done on [ICRSC].
||Classes| Approval of training classes is done on [ICRSC].
||Clock Entries (Authorize)|Approval of clock entries may be done on [ITAPC] or [WATAPC] or [WVTAPC].
||Courses| Approval of training courses is done on [ICRS].
||Development Activities| Approval of activities created for development programs is done on [ICDA] or [ICDP].
||Development Programs| Approval of development programs is done on [ICDP].
||Job Requisitions| Approval of job requisitions is done on [IRPO] and [IRPOA].
||Leave Lines| Approval of leave requests is done on [IAAL].
||Open Enrollment EEs|Approval of Employee Open Enrollments is done in [IBPOE].
||Pay Header Batches| Not currently available
||Pay Transaction Batches| Approval of payroll transaction batches is done in [IPTR] or [IPTRB].
||Performance Reviews| Approval of performance reviews is done on [ISRV] and [ICPD].
||Personnel Actions| Approval of personnel actions is done on WxDAR and [ISPA] through the [MSSPA] dialog.
||Positions| Approval of positions is done in an extended version of [IDPS].
||Time Sheets| Approval of time sheets is done on WxDATS, WxPTS, WxTTC, WxTTS and [IPTS] through the [MPAPTS] dialog.
||Training Resources| Approval of training resources is done on [ICRS] and [ICRSC].
----
!!How to Define an Approval Process
Processes are defined in the Define Approval Process [IDAP] form with an [Approval Process code|APPROVAL_PROCESS_CODE], along with the [type|APPROVAL_TYPE] of approval and a description.
Approval processes can be refined using a where clause. The where clause acts as a filter to qualify the transactions that are to be handled by the process.
For example, if there is a special set of approval rules for wage changes, an approval process may be defined with a 'Personnel Action' approval type and a where clause that restricts the process to PA’s that have a change reason of “A WAGE INCREASE”. All other types of PA’s would not qualify.
%%information For more information on using where clauses in an approval process please read the [Using Where Clauses in Approvals|WHERE CLAUSES IN APPROVALS] page.%%
!Approval Processes
A priority may be specified to indicate the order in which the approval processes are checked. The priority will be used when the approval service is deciding which process applies to the approval entity. Processes are grouped by type and ordered from highest to lowest.
%%warning Caution should be used since if left empty, the ID value will be substituted, which may cause unexpected results if there are multiple occurrences of the same approval type. The suggested set up is to define a priority when multiple of the same type exist.%%
Approval processes can also be defined using a start date and/or end date where the rules are considered to be effective. If the current processing "as of" date falls within the time frame specified (or after the start if the end date is not provided or before the end date if the start date is not provided) the approval is considered effective.
!What are Priorities?
When you have more than one approval process for any given approval type that are differentiated by using where clauses, in order to ensure that they are processed properly, they must be given a processing priority.
To get the best performance, processing should begin with the most specific approval processes that affects the smallest group of employees and finish with the most general approval process that will process all remaining employees (the largest group).
This accomplishes two objectives:
#Employees are processed in the proper order and eliminated from further processing which is more efficient.
#More importantly, it also prevents employees who are both part of a general group (entity) as well as a specific group (department) from getting processed and eliminated from further processing as part of general group before they get processed in their proper specific group.
Example: You have a situation where Department A has a different benefit election approval process than the rest of the company. If you set the priority for Department A’s approval process to be prepared after the approval process for the rest of the company, then all employees in Department A will be processed as part of the whole company and will never be processed as Department A. However, if you set the priority to process Department A first, they will be processed correctly, eliminated from further processing, and then the rest of the company will be processed as required.
%%information No employee in the organization will ever be processed twice for the same approval type. Once someone has qualified they are excluded from further processing.%%
!Setting up by Approval Type with Sub Types
Within Personnel Actions approval type, there are many PA sub-types and within each PA sub-type there can be many approval processes.
Each approval process within each PA sub-type will need to follow a specific processing priority, so they can be broken down into individual series.
For example:
|4000 Series|[WEBEL]|Benefit Election Requests
|3000 Series|[WEEPP]|Personal Profile Change Requests
|2000 Series|[WMEPR]|Promotion Requests
|1000 Series|[WMETR]|Termination Requests
Within each series, set the processing priority for the different sub-types, starting with the most specific, and ending with the least specific.
[Example of Approval Type with Sub Types|EXAMPLE APPROVAL WITH SUBTYPES]
!Approval Steps
For each process, multiple [steps|APPROVAL STEPS] or at least a minimum of one step must be defined, sequenced and given a description. For each step, [approvers|APPROVERS] and approval records may be maintained and viewed.
!Approval Work Flow Notification
Approval Records are used in several ways to compliment the approval system. One of the usages is Work Flow. Work flow is provided on the table p2k_cm_approval_records.
This enhances approvals by adding all standard features of work flow such as emails, user calcs and in turn procedures.
The term “Notification records” has been used to describe the records created to “notify” an approver, say for example an assignment manager of a pending approval via email using work flow. If on step one an approver is required to make an approval. Once the approval entities stage is set to Stage_waiting_approval, an approval record or notification record is created. This record has a status of “Ready to be Approved” as defined in the lexicon X_APPROVAL_STATUS. Up to Approvers also get a notification record with the status of “Approval In Progress”
!Approval Deletion or Cancellation
Since approval records are used in a few ways to notify approver of pending approvals like screens (SS) and work flow, approval records are maintained in cases where the approval entity is deleted or cancelled. The approval record status is updated to cancelled and will have a comment made if deleted.
Cancelled Example:
Deleted Example: Status is cancelled with a comment showing the entity was deleted.
!!Approval Screens
Approval screens include different types to define, view, maintain and approve. This is possible in both eP and Self service. Some of the main driving screens are listed below for eP. Self service has specific notation to the function name as WV???? and are located on several menus but generally in administrator or manager type roles.
!Define Approval Process - ([IDAP])
Used to create approval processes, steps, approvers and to view approval records.
!View Pending Approval Records - ([IDVAP])
Used to View approval records which are “ready to be approved” indicating an approval process waiting approval. This will show all the identities for each step which could actually make the approval.
!View All Approval Records - ([IDVAR])
Used to view approval details and approve if the user has approval rights. This function is dynamic and displays different details specific to the approval entity. The example below is for a personnel action.
!View Approval Records - ([DDAPR])
Details of approvals and notifications may be viewed by day.
The [Approval Bar and Approval Action Button Functions|APPROVAL BAR AND BUTTON FUNCTIONS] page provides a list of the functions with either an approval bar or approval action button.
!!DEFAULT FUNCTIONALITY
!Approval Stages
Approval Entities are managed by stages. Simplified for example - “before”, “during” and “after”. Each stage is mapped for each approval entity. This enables each entity to manage them selves to their specific business status descriptions. These are lexicon columns on the entity which describe their status or authorization requirements. The personnel actions mapping is given as an example below. For this example the “before” is stage_WorkInProcess, “during” is Stage_WaitingApproval and “after” is either “Stage_approved”, “Stage_Not_approved” or “Stage_Cancelled”
Personnel Actions – PA Status mappings translating from pa_status to approval stage.
|Pending |Stage_WorkInProcess
|In Progress| Stage_WaitingApproval
|Submitted |Stage_WaitingApproval
|Failed Update| Stage_Approved
|Approved |Stage_Approved
|Completed |Stage_Approved
|Not Approved| Stage_Not_Approved
|Tracked Copy| Stage_Cancelled
|Cancelled| Stage_Cancelled
Personnel Actions – PA Status mappings translating from approval stage to pa_status
|Stage_WorkInProcess| Pending
|Stage_Not_Approved| Not Approved
|Stage_Cancelled| Cancelled
|Stage_WaitingApproval| In Progress
|Stage_Approved| Approved
!Generic Approvals
It is not necessary to always define an approval processes. When simply a sanity check of the data is required and anyone or everyone is required to review the data on the approval entity before it moves to the next status value, generic approvals may be used.
If an approval entity is moved to the approval stage “Stage_WaitingApproval” and there has not been an approval process defined a generic 1 step approval bar will be displayed. Any user with access to the function and data may approve this type of approval. No approval records are ever created. The status of the approval entity is simply updated to the next stage upon approval.
A generic approval would be displayed as below with the right mouse click menu:
!Find Block Approval Toggles (Obsolete)
This section has been replaced with the site preference described below available in 4.09
Two self service screens listed below have a toggle available for use located in the find block of each function. This toggle enables the data listed in the find block to change dynamically to show “potential” approvals verses “actual” approvals.
|WVDATS|Approve Time
|WVTSH|Approve Employee Time and Exceptions
It is highly recommended that properly built where clauses are used on both the approval process and approver levels. If the refining of approval processes and approvers is not properly done performance will be an issue. Consultants would be a good source to help ensure that all filtering is done properly to avoid any performance problems. Below is an example of too many rows for an approver to manage.
!!Site Preferences
The site preference APPROVAL_WIP_REC now replaces the old simulation logic applied when trying to find the possible approvals an approver may need to make. This logic gives more of an accurate view of the up and coming approvals by monitoring specific tables defined by this preference.
In IMST, preference records may be added as in the above example for table TIME
[{If var='loginstatus' contains 'authenticated'
----
![Discussion|Edit:Internal.APPROVAL+PROCESS]
[{InsertPage page='Internal.APPROVAL+PROCESS' default='Click to create a new discussion page'}]
}]