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
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 [{$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.
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 10 changed one line
||Benefit Elections| Approval of benefits selected on the [{$applicationname}] 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 13 removed one line
||Classes| Approval of training classes is done on [ICRSC].
At line 17 added one line
||Education| Approval of Candidates Education can be done in [IRCA] within the Education tab.
At line 26 added one line
||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 28 changed one line
||Work History| Approval of Candidates Work History is done in [IRCA] within the Work History tab.
At line 32 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 34 changed one line
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, a Personnel Action type approval process can be set up with 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. For more information on using where clauses in an approval process please read the page [Using Where Clauses in Approvals|WHERE CLAUSES IN APPROVALS].
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 36 changed one line
A priority may be specified to indicate the order that 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. 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.
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 38 changed one line
Approval Processes can also be defined using a start date and/or an end date where the rules are considered to be “effective”. If the current processing as of date falls within the time frame specified the approval is considered effective.
%%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 40 removed 126 lines
!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 (smallest) group of employees and finish with the least specific (largest) group. High priority numbers are processed first. Therefore, you want to process the most specific (smallest) Approval Process first and end with a general Approval Process that will process all remaining employees.
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 processed 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.
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 the Approval Type of Personnel Actions there are many PA Types and within each PA Type there can be many Approval Processes.
Each Approval Process within each PA Type will need to follow a specific processing Priority, so can break them down into 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 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.
!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 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 [{$applicationname}] can only be used in this selection. These people lists use the “WHERE CLAUSE” functionality as defined in [IMDAO].
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.
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.
;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|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”
;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 canceled. The approval record status is updated to cancelled and will have a comment made if deleted.
\\
----
\\
!!Overview
!Intent
To outline functionality in the eP2k Professional and Self Service application approvals, using Approval Processes, Approval Steps, Approvers, Designated Approvers, and Approval Records. \\
Topics covered:
*Approval process definition
*Designated approvers
*Approval process and approver where clauses
*Approval User interfaces
*Approval Screens
*Default functionality
**Empty Approval Steps
**Approver Options
**Approval Stages
**Approval Records ( new 20100423 )
**Final Approval
**Approval Notification / Work Flow
**Approval entity deletion or cancellation
**Generic approvals
**Find block approval toggles
Audience
Any company requiring approval/authorization of the supported “Approval Entities” listed below as defined in the lexicon “X_APPROVAL_TYPE”
||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
At line 167 removed one line
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 169 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.
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 171 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.
%%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 173 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.
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 175 changed 6 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.
!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 182 changed 23 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
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.
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 206 changed 34 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.
Approval User Interfaces
Approvals may be made using 2 different types of interfaces. The most common interface is the approval bar and the second is the approval action button. The approval bar is a graphical representation with added features to see the state of the approval process. The approval button simply makes an approval with available optional comments.
Approval Bar
The approval bar is divided into sections which represent each step in the process. The description of each step is displayed in bold to identify the step. Below the description is 1 approval record status used to describe that status of that step. In the example above an approval has been made on step 1 by the department manager and step 2 is ready to be approved by the HR personnel approver. To help show the status of each step is 2 chevrons colored green and red. Green notes an approval has been made and red notes a step waiting approval.
Each step has two methods of making an approval. The first is the quick approve, noted as a check mark on the step which the approver (user) has rights to approve. If the user is not an approver with rights to approve the quick approve is not available. When the quick approve is clicked an approval is made and the process is progressed to the next step or final approval as required. An option to make comments is not available.
The second is a menu available with a right mouse click over the waiting step. The first menu item is a text item showing the approver name. The three options following that are approve, decline and send back with comments.
The approve action on the menu provides an option to add comment to the approval via a dialog.
The dialog has an optional comment box and approve or cancel action buttons. The approve will advance the process to the next step or make the final approval as required.
The approval bar menu also provides the same type of dialog for Decline with comments and Send back with comments.
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.
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 241 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.
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 245 changed 5 lines
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.
IDAP –
Used to create approval processes, steps, approvers and to view approval records.
%%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.%%
At line 63 added 2 lines
!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 252 changed 3 lines
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.
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 256 changed 6 lines
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.
DDAR -
Details of approvals and notifications may be viewed by day.
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 263 changed 80 lines
The following functions have an approval bar or approval action button where an approval may be made.
Product Function Function Description / Menu Label GUI
AT IAAL Maintain Leave Records Approval Bar
AT IALC Certify Leave Records Approval Bar
AT WMALP Review Employee Leaves Approval Bar
BE IBEL Process Benefit Elections Approval Bar
BE IBPOE Process Employee Benefit OE Elections Approval Bar
CM IDPS Define Positions Approval Bar
CM WADAR Process Personnel Actions Approval Bar
CM WADARH View Personnel Actions History Approval Bar
CM WADATS Approve Time Action Button
CM WMDAR Review Personnel Actions Approval Bar
CM WMDARH View Personnel Action History Approval Bar
CM WVDALR Approve Leave Requests Approval Bar
CM WVDAR Approve Personnel Actions Approval Bar
CM WVDARH View Personnel Action History Approval Bar
CM WVDATS Approve Time Approval Bar
CP ICDA Plan Development Activities Approval Bar
CP ICDP Establish Development Programs Approval Bar
CP ICPD Maintain Personal Development Profile Approval Bar
CP ICRS Define Courses Approval Bar
CP ICRSC Maintain Class Schedules Approval Bar
CP ICRSE Maintain Class Registrations Approval Bar
CP WACAT Process Training Requests Approval Bar
CP WMCAT Review Training Requests Approval Bar
CP WMCATH View Training Request History Approval Bar
CP WVCAT Approve Training Requests Approval Bar
CP WVCATH View Training Request History Approval Bar
HR PEAL Maintain Aliases (using PA's) Approval Bar
HR PEAS Maintain Assignment Info (using PA's) Approval Bar
HR PECL Process Classification Changes (using PA's) Approval Bar
HR PECMP Process Compensation Changes (using PA's) Approval Bar
HR PECT Maintain Employee Contacts (using PA's) Approval Bar
HR PEEI Maintain Employment Info (using PA's) Approval Bar
HR PEID Maintain Identity Info (using PA's) Approval Bar
HR PEMT Maintain Military Info (using PA's) Approval Bar
HR PEPI Maintain Personal Info (using PA's) Approval Bar
HR PEPP Maintain Property Info (using PA's) Approval Bar
HR PEPR Process Promotions (using PA's) Approval Bar
HR PEST Maintain Employee Statistics (using PA's) Approval Bar
HR PESTT Process Status Changes (using PA's) Approval Bar
PR IPTR Maintain Pay Transactions Approval Bar
PR IPTRB Balance Pay Transactions Approval Bar
PR IPTS Enter Employee Time Sheets Action Button
PR IPTS Maintain Employee Time Sheets Action Button
PR MPPBT Dialog Approval Bar
PR PPPM Maintain Payment Method Info (using PA's) Approval Bar
PR PPRLC Maintain CDN Tax Filing Info (using PA's) Approval Bar
PR PPRLU Maintain US Tax Filing Info (using PA's) Approval Bar
PR WAPTE Manage Time Collection Hours Action Button
PR WAPTS Manage Time Cards Action Button
PR WEPTE My Time Collection Hours Action Button
PR WMPCTC Review Employees Time Cards - Calendar View Action Button
PR WMPTS Review Time Cards Action Button
PR WVPTE Manage Time Collection Hours Action Button
PR WVPTS Approve Time Cards in Detail Action Button
RE IRAS Prepare Assessments Approval Bar
RE IRCA Maintain Candidate Profiles Approval Bar
RE IRPO Maintain Postings Approval Bar
RE IRPOA Approve Postings Approval Bar
RE WARPO Maintain Postings Approval Bar
RE WRRAP View Applications By Posting Approval Bar
RE WRRMCA Maintain Candidate Profiles Approval Bar
SA ISPA Maintain Personnel Actions Approval Bar
SA ISPF Balance Pay for Performance Increases Action Button
SA ISRV Record Performance Reviews Approval Bar
SA MSSPA Dialog Action Button
SA WMSRV Review Employee Appraisals Approval Bar
SA WVSRV Approve Performance Appraisals Approval Bar
TS ITAPC Approve Clock Adjustments Approval Bar
TS WATAPC Authorize Punch Changes Approval Bar
TS WATTS Manage Time Sheets Action Button
TS WATTX Manage Time Collections Action Button
TS WMTAPC Authorize Punch Changes Approval Bar
TS WMTTS Review Time Sheets Action Button
TS WVTAPC Authorize Punch Changes Approval Bar
TS WVTSH Approve Employee Time and Exceptions Action Button
TS WVTTS Approve Time Sheets in Detail Action Button
TS WVTTSH View Time Sheet History Action Button
TS WVTTX Manage Time Collections Action Button
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 344 changed 17 lines
DEFAULT FUNCTIONALITY
Empty Approvers
When an approval process has been initiated each step is displayed in the approval bar which is visible in certain approval screens. Approvers who qualify for approval by the where clause will be notified of a pending approval to be made. After such approval the next step is assessed for the current approvers. If the next step is lacking approvers from either an empty definition or the defined approver is disqualified via a where clause that empty step is ignored.
When a step is ignored it will not show in the approval bar or have approval notification records created. It will appear as if the approval process did not have that step defined. When the empty step is the last step in the process the last approval made will be considered final approval and the approval entity will be updated to the “approved” stage.
Example:
Approval Process – Where clause = PEAS Personnel Actions only.
Step 1, Approver = Department Manager (no where clause)
Step 2 , Approver = HR personnel Specific person ( Where Clause – where wage Scale/Step is the last step sequence 3)
The assignment manager creates a new Personnel Action for a salary increase in PEAS for a salary increase to the next step. (2 of 3)
Notice only 1 step is displayed and the approval process includes two steps.
The approver where clause disqualifies the last approver.
Approval by the Department manager will result in final approval and the personnel action will become available for processing.
[Example of Approval Type with Sub Types|EXAMPLE APPROVAL WITH SUBTYPES]
At line 362 changed 4 lines
Approver Options
Approvers may be defined with fours options. These options are “up to approval”, “allow send back”, “allow decline” and “allow change”. Only applies to a second level of approval or higher. Once that level of approval is reached the approver will be notified of the pending approval. At that time the approver now has three possible actions to make.
!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 367 changed 4 lines
Up to Approval
When Up to Approval is checked that approver is eligible to approve entities which they qualify for via the where clause, including entities that are waiting approval on a step with a lower sequence. When up to approval is granted “notification records (approval records)” will be created with a status of “Approval In Progress” (Notification records are discussed further in Approval Notification /Workflow).
!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].
At line 372 changed 8 lines
Allow Send Back
This setting applies to a second level of approval or higher. If at the time of approval the approver does not like what they see the option to send the entity back to the beginning of the approval process is available. This will set all previous step approvals (approval records) to have a status of “Approval Sent Back” which will cause the first step approvers to be notified (via new approval records) to once again approve the entity. Comments as to why the send back was made may be entered if necessary.
This option is available in eP as an option in the right mouse click menu over the appropriate step on the approval bar.
Allow Decline
This setting allows the approver to decline the approval entity. The option is applicable to all steps the approver is responsible for. If a decline is made the approval process is complete, no further approval notification is necessary. This option is available in the right mouse click menu. Comments as to why the decline was made may be entered if necessary.
This enhances approvals by adding all standard features of workfflow such as emails, user calcs and in turn procedures.
At line 381 changed 4 lines
Allow Change
This setting will cause the approval entity to be editable or not during the approval. In cases where the approver is allowed to view only while making the approval.
Change is allowed.
Notice the updateable details of the PA:
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 386 changed 4 lines
Change is NOT allowed.
Notice the non-updateable details of the PA:
Once an approval entity has entered the approval stage (explained below) of "Stage_WaitingApproval" CRUD will be controlled to the appropriate approver. This means that only approvers who have rights to approve on the current step with "allow change" rights will be able to edit the information displayed.
!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 391 removed 60 lines
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
Approval Records
Each stage dictates what approval records are created. The Approval records are what is used to create a visual (approval bar) or report ( discoverer) to show where and who the approval sits, whether it`s before during or after the approval.
The current supported approval record statuses are:
Approval Cancelled
Future Approval
Ready To Be Approved
Approval In Progress
Approved
Sent Back
Approved Sent Back
Approved Historic
Declined
Declined Historic
Approval Cancelled - used when an entity is cancelled or deleted. All existing approval records will receive this status. (explained in a following section)
Future Approval - used for up and coming approvals to be made for an approver who do not have upto approval. Approval Stages which cause this are Stage_WorkInProcess or Stage_WaitingApproval. For the Stage_WorkInProcess futural Approvals are optional and can be controlled but a site preference defined in IMST. Each table where approvers need as much time a possible before the actual approval is required may be defined. in the example screen shot below. Future approval records will be created when either a Time sheet or Personnel Action is set to a WIP status. Example: This may be helpful for managers with employees that have time sheets which have not been submitted for approval.
Ready To Be Approved - used for approvers which are required to make approval decisions.
Approval In Progress - used to show approvers with `Up To approval` that there is an approval in progress which they can make an up to approval on.
Approved - used to show a positive approval
Sent Back - used to show the approval process has been requested to start over.
Approved Sent Back - used to show a lower step positive approval has been send back to be re-done.
Approval Historic - used to show and entity has had a positive approval but is no longer needed either through a cancel or deletion.
Declined - used to show a negative approval.
Declined Historic - used to show a negative approval was made and is no longer needed either though a cancel or deletion.
Maintenance of approval records is accomplished in three ways. The first is automatically by the system when an existing IDAP definition pre-exists to an approval process starting and does not change during the approval. Secondly a manual button is on IDAP to update records if the approval process has been updated in any way with approvals in progress.
The third is to run an update process UDAP. This process is suggested to be scheduled daily to allow start and end dates to be respected in IDAP processes or approvers, where clauses or designate approvers.
Final Approval
Is a term used to describe any approval process that is in progress which has an approval made where it is deemed the last approval required for the process. This is possible for example in cases of missing approvers or an approval on the last step. Once final approval is made, the approval entity is updated to the “approved” stage
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.
At line 454 removed one line
At line 456 changed 4 lines
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.
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.
At line 101 added 2 lines
|[WVDATS]|Approve Time
|[WVTSH]|Approve Employee Time and Exceptions
At line 462 changed 3 lines
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.
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.
At line 466 changed 4 lines
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
At line 471 changed 4 lines
Site Preferences (New as of 4.09)
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.
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.
At line 476 changed one line
In IMST, preference records may be added as in the above example for table TIME
In [IMST], preference records may be added for table aliases, such as PTS.
At line 478 removed 14 lines
[{If var='loginstatus' contains 'authenticated'
At line 493 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 496 removed one line
}]
This page (revision-69) was last changed on 26-Nov-2021 10:22 by kparrottTop