This page (revision-23) was last changed on 26-Nov-2021 10:22 by Karen Parrott

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

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
23 26-Nov-2021 10:22 31 KB Karen Parrott to previous
22 26-Nov-2021 10:22 31 KB kparrott to previous | to last
21 26-Nov-2021 10:22 31 KB kparrott to previous | to last

Page References

Incoming links Outgoing links
APPROVALS AND AUTHORIZATIONS
APPROVALS AND AUTHORIZATIONS

Version management

Difference between version and

At line 28 changed one line
Any company requiring approval/authorization of the supported “Approval Entities” listed below as defined in the lexicon [X_APPROVAL_TYPE]
Any company requiring approval/authorization of the supported 'Approval Entities' listed below as defined in the lexicon [X_APPROVAL_TYPE]
At line 30 changed 26 lines
Abbreviation Stored Value
Pay Trans Batches 02
Pay Header Batches 03
Performance Reviews 04
Personnel Actions 05
Time Entries 06
Job Requisitions 07
Applicant Hires 08
Development Programs 09
Development Activity 10
Courses 11
Class Schedules 12
Training Resources 13
Benefit Elections 14
Assessments 15
Class Registration 16
Time Sheets 17
Leave Lines 19
Clock Entries (Authorize) 20
Education 21
References 22
Work History 23
Open Enrollment EEs 24
Positions 25
Time Sheet Entries (Authorize) 26
!!APPROVAL PROCESS DEFINITION
!Approval Processes [IDAP]
Processes are defined in IDAP with a APPROVAL_PROCESS_CODE which is standard to all code fields in eP, a type of approval being defined using the APPROVAL_TYPE and a description.
At line 57 changed 2 lines
Prerequisites
Functionality described follows the eP version 4.08.60
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.
At line 60 changed 6 lines
APPROVAL PROCESS DEFINITION
Approval Processes
Processes are defined in IDAP with a APPROVAL_PROCESS_CODE which is standard to all code fields in eP, a type of approval being defined using the APPROVAL_TYPE and a description.
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.
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 P's of type: "ADDRESS CHANGE" do not.
At line 38 added 4 lines
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.
At line 68 changed 5 lines
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 are defined by selecting an Approver Type. Supported Approver types as defined in X_APPROVER_TYPE lexicon are listed below.
!Approvers
Approvers are defined by selecting an Approver Type. Supported Approver types as defined in [X_APPROVER_TYPE] lexicon are listed below.
At line 74 changed 16 lines
Abbreviation Stored Value
Department Manager 01
Position Manager 02
Assignment Manager 03
First Manager 04
Specified Person 07
Spec List Of People 08
Last Approvers Manager 09
All Managers 10
Approvers may be restricted using a “WHERE_CLAUSE” (IMDAO) to which approval entity they can approve within this process.
Example: For the PA beginning approved above The PROCESS has already said that only PA’s of type “A WAGE INCREASE” will be approved. And the specified approver can now only approve PA’s for employees in a specific “DEPARTMENT”.
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 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 ep2k can only be used in this selection. These people lists use the “WHERE_CLAUSE” functionality as defined in IMDAO
||Abbreviation||Stored Value
|Department Manager|01
|Position Manager|02
|Assignment Manager|03
|First Manager|04
|Specified Person|07
|Spec List Of People|08
|Last Approvers Manager|09
|All Managers|10
At line 56 added 11 lines
Approvers may be restricted using a "WHERE_CLAUSE" (IMDAO) to which approval entity they can approve within this process.
Example: For the PA beginning approved above The PROCESS has already said that only PA's of type "A WAGE INCREASE" will be approved. And the specified approver can now only approve PA's for employees in a specific "DEPARTMENT".
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 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.
At line 92 changed 5 lines
Approval Records
Approval Records contain such information as the Approval timestamp the Status of the approval 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 To Be Approved”. There is one record for each identity defined as an approver for the first step of approval. These record in conjunction with work flow can be used to notify 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.
%%information People lists that are generated through ep2k can only be used in this selection. These people lists use the "WHERE_CLAUSE" functionality as defined in [IMDAO]%%
At line 70 added 2 lines
!Approval Records
Approval Records contain such information as the Approval timestamp the Status of the approval The reference ID the approval is for.
At line 73 added 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 To Be Approved". There is one record for each identity defined as an approver for the first step of approval. These record in conjunction with work flow can be used to notify approvers of pending approvals.
At line 100 changed 4 lines
DESIGNATED APPROVERS
/
Approvers may be replaced by a designated approver for a defined time frame or indefinitely for specific approval types known as Designated Approvers in IEMDA. Approvers may also maintain who is designated as an approver in their absence using IEDA.
Approvers may designate a temporary replacement in two capacities. Either a “Replacement” or an “Alternate” may be defined. Replacement designates relieve an approver of all approval responsibilities starting as of the “From date” and end on the “To date” starting at 12am on the date specified. If these dates are left blank (null) the beginning of time and end of time are assumed respectively. When an alternate is defined all responsibilities are shared by the specified person and the original approver.
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:
#The current step and its next defined step.
#The step that the approver identity is part of and if that identity is an up to approver.
#If there are any more steps in the process.
At line 82 added 5 lines
!!DESIGNATED APPROVERS
IEDA/IEMDA
Approvers may be replaced by a designated approver for a defined time frame or indefinitely for specific approval types known as Designated Approvers in IEMDA. Approvers may also maintain who is designated as an approver in their absence using IEDA.
Approvers may designate a temporary replacement in two capacities. Either a "Replacement" or an "Alternate" may be defined. Replacement designates relieve an approver of all approval responsibilities starting as of the "From date" and end on the "To date" starting at 12am on the date specified. If these dates are left blank (null) the beginning of time and end of time are assumed respectively. When an alternate is defined all responsibilities are shared by the specified person and the original approver.
At line 106 changed 2 lines
Both types of replacements may be specific to a certain type of approval.
Ex: a Manager may be away for a vacation and time sheets may need to be reviewed during that time frame so an alternate or replacement may be assigned specifically to “Time Sheets”. If there was a salary review during that time, it would remain the responsibility of the original manager to approve.
Both types of replacements may be specific to a certain type of approval.
Ex: a Manager may be away for a vacation and time sheets may need to be reviewed during that time frame so an alternate or replacement may be assigned specifically to "Time Sheets". If there was a salary review during that time, it would remain the responsibility of the original manager to approve.
At line 109 changed 8 lines
When responsibility is transferred from the approver to the designate for a replacement, all approval records previously created for notification are moved from the approver to the designate when the new designate record is saved. This will cause work flow, all approver screens and self service splash “to do” lists to now be full for the existing approvals previously required for the approver. Any new approvals required will create new approval records for the designate and the original approver will not be notified.
Alternate designates will have a copy of the approval records created for them and the original approver will retain all existing approval records. Both the alternate and approver will receive notification of new pending approvals.
The maintenance of the approval records as described above will be limited to the specified approval types. If none are listed all approval records will be subject to this maintenance.
APPROVAL PROCESS AND APPROVER WHERE CLAUSES
A where clause may be defined in IMWC or IMDAO.
/
Once a where clause is defined it may be used to control what gets approved and by whom when using it at two levels. The first is by the approval process itself and the second is by each approver. In both cases the where clause must be relative to the approval entity as the base table.
When responsibility is transferred from the approver to the designate for a replacement, all approval records previously created for notification are moved from the approver to the designate when the new designate record is saved. This will cause work flow, all approver screens and self service splash "to do" lists to now be full for the existing approvals previously required for the approver. Any new approvals required will create new approval records for the designate and the original approver will not be notified.
Alternate designates will have a copy of the approval records created for them and the original approver will retain all existing approval records. Both the alternate and approver will receive notification of new pending approvals.
The maintenance of the approval records as described above will be limited to the specified approval types. If none are listed all approval records will be subject to this maintenance.
!!APPROVAL PROCESS AND APPROVER WHERE CLAUSES
A where clause may be defined in IMWC or IMDAO.
[IMWC]/[IMDAO]
Once a where clause is defined it may be used to control what gets approved and by whom when using it at two levels. The first is by the approval process itself and the second is by each approver. In both cases the where clause must be relative to the approval entity as the base table.
At line 120 changed 2 lines
This condition is attempting to restrict to a position code. In order to do that the condition must start from a column on p2k_sa_personnel_actions. This example works its way from p2k_sa_personnel_actions then to the prime assignment on p2k_hr_assignments ,then to the effective details of that assignment (p2k_hr_assignment_details), then to the position (p2k_cm_positions) on that assignment as noted from the foreign keys in the condition column. The “value” is the restricted position code.
APPROVAL USER INTERFACES
This condition is attempting to restrict to a position code. In order to do that the condition must start from a column on p2k_sa_personnel_actions. This example works its way from p2k_sa_personnel_actions then to the prime assignment on p2k_hr_assignments ,then to the effective details of that assignment (p2k_hr_assignment_details), then to the position (p2k_cm_positions) on that assignment as noted from the foreign keys in the condition column. The "value" is the restricted position code.
!!APPROVAL USER INTERFACES
At line 123 changed one line
Approval Bar
__Approval Bar__
At line 114 added one line
At line 116 added one line
At line 132 changed one line
The approval bar menu also provides the same type of dialog for Decline with comments and Send back with comments.
The approval bar menu also provides the same type of dialog for Decline with comments and Send back with comments.
At line 134 changed one line
The last part of the approval bar is the information icon located to the immediate right of the approval bar. When clicked this action displays a view only dialog showing a record representation of the existing state of the approval proceeds based on the current approval records. Details shown include Date and time of the approval record creation, Step sequence, Status of the approval record, Approver Type, The identity for which the approval record was created, and optional comments made by an approver. These details may be viewed with more detail by day in DDAPR (see the Approval Screens section below) This dialog is based on the form (function) MDAPR.
The last part of the approval bar is the information icon located to the immediate right of the approval bar.
When clicked this action displays a view only dialog showing a record representation of the existing state of the approval proceeds based on the current approval records. Details shown include Date and time of the approval record creation, Step sequence, Status of the approval record, Approver Type, The identity for which the approval record was created, and optional comments made by an approver. These details may be viewed with more detail by day in DDAPR (see the Approval Screens section below). This dialog is based on the form (function) MDAPR.
At line 136 changed 3 lines
Approval Action Button
The second type of interface is simply an action button located on various forms. The approval screens list below includes the type of action GUI provided.
!Approval Action Button
The second type of interface is simply an action button located on various forms. The approval screens list below includes the type of action GUI provided.
At line 140 changed 2 lines
Approval Screens
!!Approval Screens
This page (revision-23) was last changed on 26-Nov-2021 10:22 by Karen ParrottTop