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 76 changed one line
[Approvers|APPROVERS] are defined by selecting a supported Approver type, which are defined in the [X_APPROVER_TYPE] lexicon.
[Approvers|APPROVERS] are defined by making a selection from the [Approver type|X_APPROVER_TYPE]lexicon.
At line 78 changed one line
[Approvers|APPROVERS] may be restricted using a Where Clause ([IMDAO]) that will indicate which approval entity they can approve within this process.
!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].
At line 80 changed one line
Example: For the PA being approved, the process indicates 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 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.
Both types of replacements may be specific to a certain type of approval.
At line 82 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).
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.
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.
At line 84 changed one line
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 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.
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.
At line 86 changed one line
The “Specified Person” is the selected identity as the qualified approver the above approval step.
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.
At line 88 changed one line
The “List of People” allows all identities in the list as qualified approvers.
!Approval Process And Approver Where clauses
At line 90 changed one line
Note: People lists that are generated through [{$applicationname}] can only be used in this selection. These people lists use the “WHERE CLAUSE” functionality as defined in [IMDAO].
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.
Example:
Personnel Action where clause:
At line 92 changed one line
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].
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.
At line 120 removed 2 lines
Audience
Any company requiring approval/authorization of the supported “Approval Entities” listed below as defined in the lexicon [X_APPROVAL_TYPE]
At line 123 removed 26 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.
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.
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.
Example:
Personnel Action where clause:
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.
This page (revision-69) was last changed on 26-Nov-2021 10:22 by kparrottTop