This page (revision-69) was last changed on 26-Nov-2021 10:22 by kparrott

This page was created on 26-Nov-2021 10:22 by JLawler

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
69 26-Nov-2021 10:22 9 KB kparrott to previous
68 26-Nov-2021 10:22 9 KB jmyers to previous | to last APPROVAL_WIP_REC ==> APPROVAL_WIP_REC(System_Preference)
67 26-Nov-2021 10:22 9 KB JEscott to previous | to last
66 26-Nov-2021 10:22 9 KB JEscott to previous | to last
65 26-Nov-2021 10:22 9 KB JEscott to previous | to last
64 26-Nov-2021 10:22 9 KB JEscott to previous | to last
63 26-Nov-2021 10:22 9 KB JEscott to previous | to last
62 26-Nov-2021 10:22 9 KB JMyers to previous | to last
61 26-Nov-2021 10:22 9 KB JMyers to previous | to last

Page References

Incoming links Outgoing links
APPROVAL PROCESS
APPROVAL PROCESS

Version management

Difference between version and

At line 3 changed one line
Approval Processes are user defined on the [IDAP] form. 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.
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.
At line 5 changed one line
Approvals may be done in eP 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 eP or HR Self Service can view and approve transactions initiated by the employees they are authorized for.
Approvals may be done in Personality 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 Personality or HR Self Service can view and approve transactions initiated by the employees they are authorized for.
At line 7 changed one line
!What can be approved?
!!What Can Be Approved?
At line 10 changed one line
||Benefit Elections| Approval of benefits selected on the eP or Self Service election forms is done on [IBEL] or WxDAR.
||Benefit Elections| Approval of benefits selected on the Personality or Self Service election forms is done on [IBEL] or WxDAR.
At line 12 changed one line
||Classes| Approval of training classes is done on [ICRSC].
||Class Schedules| Approval of class schedules is done on [ICRSC].
||Clock Entries (Authorize)|Approval of clock entries may be done on [ITAPC] or [WATAPC] or [WVTAPC].
At line 17 added one line
||Education| Approval of Candidates Education can be done in [IRCA] within the Education tab.
At line 20 added one line
||Open Enrollment EEs|Approval of Employee Open Enrollments is done in [IBPOE].
At line 25 added 2 lines
||Positions| Approval of positions is done in an extended version of [IDPS].
||References| Approval of Candidates References is done in [IRCA] within the References tab.
At line 28 added one line
||Time Sheet Entries (Authorize)|Approval/Authorization of time sheet entries may be done in [WVPATC].
At line 30 added 3 lines
||Work History| Approval of Candidates Work History is done in [IRCA] within the Work History tab.
----
!!How to Define an Approval Process
At line 25 changed one line
Processes are defined in [IDAP] with an [Approval Process|APPROVAL_PROCESS_CODE], a type of approval being defined using the [Type|APPROVAL_TYPE] and a description.
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.
At line 27 changed one line
Ordering processes may be achieved by adding a “Priority”. 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. Caution should be used since if left empty the ID value will be substituted. This may cause unexpected results if one of many is left empty. The suggested set up is to define a priority when multiple of the same type exist.
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.
At line 29 changed one line
Processes can be refined using a WHERE CLAUSE to restrict which types will fall under the defined PROCESS. Example - a process of TYPE: Personnel Actions can have a where clause that only PA’s of type “A WAGE INCREASE” will qualify for this process defined, and such PA’s of type: “ADDRESS CHANGE” do not.
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.
At line 31 changed one line
A Process may have a “Start” and “End’ date where it will be considered to be “effective”. If the current approval entity’s AS_OF_DATE falls either between dates if both given, after the start if the end date is not provided or before the end date if the start date is not provided.
%%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.%%
At line 33 changed one line
!Approval Processes
At line 35 changed 3 lines
!Approval Steps
For each Process multiple [steps|APPROVAL STEPS] or at a minimum of one step must be defined, sequenced and given a description. For each step [approvers|APPROVERS] and approval records maybe maintained and viewed.
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.
At line 39 changed 2 lines
!Approvers
[Approvers|APPROVERS] are defined by selecting an Approver Type. Supported Approver types as defined in [X_APPROVER_TYPE] lexicon.
%%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.%%
At line 48 added one line
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.
At line 43 changed one line
[Approvers|APPROVERS] may be restricted using a “WHERE_CLAUSE” ([IMDAO]) to which approval entity they can approve within this process.
!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.
At line 45 changed one line
Example: For the PA being approved above the PROCESS has already said that only PA’s of type “A WAGE INCREASE” will be approved. And the specified [approver|APPROVERS] can now only approve PA’s for employees in a specific “DEPARTMENT”.
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).
At line 47 changed one line
[Approvers|APPROVERS] that qualify in the where clause are then assessed for their particular type. (Department Manager, Position Manager, Assignment Manager, Any Manager, Specified Person, Spec List Of People)
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.
At line 49 changed 2 lines
The “Manager” types are considered to be off the prime assignment for the identity of the approval entity. Ex: For the PA in the example above. This PA is for a specific person. The manager defined on the prime assignment either for department, position,
assignment or any person who is a manager at any of the previous levels will qualify as an approver for the above approval step.
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.
At line 52 changed one line
The “Specified Person” is the selected identity as the qualified approver the above approval step.
%%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.
At line 54 changed one line
The “List of People” allows all identities in the list as qualified approvers.
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.
At line 56 changed 2 lines
Note: People lists that are generated through eP can only be used in this selection. These people lists use the “WHERE CLAUSE” functionality as defined in [IMDAO].
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
At line 59 changed 3 lines
Alternate approvers may be defined for individual approvers so that transactions may be approved whilst the original approver is away. For more information on alternate approvers please read [Designated Approvers|DESIGNATED APPROVERS].
!Approval Records
Approval Records contain such information as the Approval timestamp, the Status of the approval and the reference ID the approval is for.
Within each series, set the processing priority for the different sub-types, starting with the most specific, and ending with the least specific.
At line 63 changed one line
When an approval Entity becomes eligible for approval, “Notification approval records” are created. These are approval records with the approval status of “Ready for Approval”. There is one record for each identity defined as an [approver|APPROVERS] for the first step of approval. These records in conjunction with work flow can be used to notify [approvers|APPROVERS] of pending approvals.
[Example of Approval Type with Sub Types|EXAMPLE APPROVAL WITH SUBTYPES]
At line 65 changed one line
Once an approval is made (for example a time sheet) an approval record is created for that identity with the appropriate status (approved, not approved, cancelled). At this time the old “notification records” are removed and notification records are created for the next step.
!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.
At line 67 changed one line
The next step will be determined by a couple of factors. 1. the current step and its next defined step. 2. the step that the approver identity is part of and if that identity is an up to approver. 3. If there are any more steps in the process.
!Approval Workflow Notification
Approval Records are used in several ways to compliment the approval system. One of the usages is Workflow, which is provided on the table [P2K_CM_APPROVAL_RECORDS].
This enhances approvals by adding all standard features of workfflow 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 workflow. 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”
At line 69 changed one line
;Approval Work Flow Notification
!Approval Deletion or Cancellation
Since approval records are used in a few ways to notify approver of pending approvals like screens and workflow, 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.
At line 71 changed one line
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.
Cancelled Example:
Deleted Example: Status is cancelled with a comment showing the entity was deleted.
At line 73 changed one line
The term “Notification records” has been used to describe the records created to “notify” an [approver|APPROVERS], say for example an assignment manager of a pending approval via email using work flow. If on step one an [approver|APPROVERS] 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”
!Find Block Approval Toggles (Obsolete)
At line 75 changed 2 lines
;Approval Deletion or Cancellation
Since approval records are used in a few ways to notify [approver|APPROVALS] 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.
This section has been replaced with the site preference described below.
At line 99 added 4 lines
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
At line 79 changed one line
[{If var='loginstatus' contains 'authenticated'
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
At line 108 added 4 lines
The site preference [APPROVAL_WIP_REC(System_Preference)] 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 for table aliases, such as PTS.
At line 82 changed 2 lines
![Discussion|Edit:Internal.APPROVAL+PROCESS]
[{InsertPage page='Internal.APPROVAL+PROCESS' default='Click to create a new discussion page'}]
![Notes|Edit:Internal.APPROVAL+PROCESS]
[{InsertPage page='Internal.APPROVAL+PROCESS' default='Click to create a new notes page'}]
At line 85 removed one line
}]
This page (revision-69) was last changed on 26-Nov-2021 10:22 by kparrottTop