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 2 added one line
At line 22 added 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.
At line 24 added 43 lines
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.
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.
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.
!Approval Steps
For each Process multiple steps or at a minimum of one step must be defined, sequenced and given a description. For each step approvers and approval records maybe maintained and viewed.
!Approvers
[Approvers|APPROVERS] are defined by selecting an Approver Type. Supported Approver types as defined in [X_APPROVER_TYPE] lexicon.
[Approvers|APPROVERS] may be restricted using a “WHERE_CLAUSE” ([IMDAO]) to which approval entity they can approve within this process.
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”.
[Approvers|APPROVERS] that qualify in the above WHERE_CLAUSE are then assessed for their particular type. (Department Manager, Position Manager, Assignment Manager, Any Manager, Specified Person, Spec List Of People)
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.
The “Specified Person” is the selected identity as the qualified approver the above approval step.
The “List of People” allows all identities in the list as qualified approvers.
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]
!Approval Records
Approval Records contain such information as the Approval timestamp, the Status of the approval and the reference ID the approval is for.
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.
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.
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.
This page (revision-69) was last changed on 26-Nov-2021 10:22 by kparrottTop