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

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
13 26-Nov-2021 10:22 10 KB JEscott to previous
12 26-Nov-2021 10:22 10 KB JEscott to previous | to last
11 26-Nov-2021 10:22 10 KB JEscott to previous | to last
10 26-Nov-2021 10:22 11 KB JEscott to previous | to last
9 26-Nov-2021 10:22 11 KB JEscott to previous | to last REQUEST_FACILITY ==> REQUEST FACILITY
8 26-Nov-2021 10:22 11 KB JMyers to previous | to last
7 26-Nov-2021 10:22 11 KB JMyers to previous | to last
6 26-Nov-2021 10:22 11 KB JMyers to previous | to last
5 26-Nov-2021 10:22 11 KB JMyers to previous | to last
4 26-Nov-2021 10:22 10 KB JMyers to previous | to last
3 26-Nov-2021 10:22 10 KB JMyers to previous | to last
2 26-Nov-2021 10:22 11 KB JMyers to previous | to last
1 26-Nov-2021 10:22 10 KB JMyers to last

Page References

Incoming links Outgoing links
REQUEST FACILITY
REQUEST FACILITY

Version management

Difference between version and

At line 1 changed 3 lines
[{TableOfContents }]
!!!REQUEST FACILITY
!!REQUEST FACILITY
At line 5 changed 7 lines
The Request facility has an email-like look and feel.
The Manage All Requests for User ([IERQ]) screen works like an email client with an Inbox, Outbox, and Archived requests section; this provides a familiar interface for users and encourages them to use requests more often in their daily work. A menu has been added to the form toolbar to make it easier for users to create new requests for a subject, as well as provide the convenience of viewing all relevant requests. [Embedded forms|EMBEDDED FORMS] which show the context of each request will be visible on [IERQ] such that when a user is viewing outstanding requests; all information is available on [IERQ] and opening other screens to understand the source of the request is no longer necessary.
Although requests are similar to email, there is no similar way to respond to a request; requests should not be replied to with another request. Instead, a user can add an activity to the current request and as long as the request remains open, the sender can see it and all activities in the Outbox of their [IERQ] screen
The Request facility has an email-like look and feel. The Manage All Requests for User (IERQ) screen works like an email client with an Inbox, Outbox, and Archived requests section; this provides a familiar interface for users and encourages them to use requests more often in their daily work. A menu has been added to the form toolbar to make it easier for users to create new requests for a subject, as well as provide the convenience of viewing all relevant requests. Embedded forms which show the context of each request will be visible on IERQ such that when a user is viewing outstanding requests; all information is available on IERQ and opening other screens to understand the source of the request is no longer necessary.
Although requests are similar to email, there is no similar way to respond to a request; requests should not be replied to with another request. Instead, a user can add an activity to the current request and as long as the request remains open, the sender can see it and all activities in the Outbox of their IERQ screen
At line 13 removed one line
At line 15 changed 3 lines
\\
----
!!When to Use Requests
When to Use Requests
At line 19 changed 23 lines
*To involve other participants in an approval process.
*To reduce emails and phone calls.
*For changes that users cannot make directly in the product.
*To document additional information that can be attached to a record for future reference.
\\
----
!!Features of the Request Facility in Personality
!Manage all Requests for User
The Manage All Requests for User ([IERQ]) screen has been redesigned to make it function more like an email client.
There are three tabs in [IERQ]: Inbox tab where incoming requests are received, Outbox tab where new requests can be created and sent to an employee, and the Archived tab where all completed or canceled requests are stored. \\ \\
Inbox tab
*Contains all requests received by the user which are still ‘open’.
*Provides the ability to complete or deny requests, as well as the ability to change the status from "New" to "In Progress".
*Users can respond to a request by adding activities, they would not respond by sending another request.
*If the request type was defined as requiring action the Action Required toggle will be checked.
*The bottom portion of the screen contains two tabs; Context and Activities.
**The Context tab will display an embedded form for the request if one has been defined in [IMRT].
**The Activities tab is a view of all activities for the request. The date the activity was added, by whom, the type of activity and the text of the activity can all be seen in this tab.
The example below depicts a request added from [IPTS] from an employee’s manager requesting additional OT to be added. The context tab displays the embedded form, [EPTS], which shows important details of the time sheet.\\ \\
[RequestFacility_01.jpg]
\\
 To involve other participants in an approval process.
 To reduce emails and phone calls.
 For changes that users cannot make directly in the product.
 To document additional information that can be attached to a record for future reference.
Features of the Request Facility in ePersonality
Manage all Requests for User - IERQ
The Manage All Requests for User (IERQ) screen has been redesigned to make it function more like an email client. There are three tabs in IERQ: Inbox tab where incoming requests are received, Outbox tab where new requests can be created and sent to an employee, and the Archived tab where all completed or cancelled requests are stored.
• Inbox tab
 Contains all requests received by the user which are still ‘open’.
 Provides the ability to complete or deny requests, as well as the ability to change the status from New to In Progress.
 Users can respond to a request by adding activities, they would not respond by sending another request.
 If the request type was defined as requiring action the Action Required toggle will be checked.
 The bottom portion of the screen contains two tabs; Context and Activities.
o The Context tab will display an embedded form for the request if one has been defined in IMRT.
o The Activities tab is a view of all activities for the request. The date the activity was added, by whom, the type of activity and the text of the activity can all be seen in this tab.
The example below depicts a request added from IPTS from an employee’s manager requesting additional OT to be added. The context tab displays the embedded form, EPTS, which shows important details of the time sheet.
At line 43 changed 5 lines
*Contains all requests sent by the user which are still ‘open’.
*Similar to Inbox features, except not allowed to cancel or complete request.
*If a request was created with a status of ‘Draft’, the creator of the request can change the status to New and send the request to the directed individual.
*Activities can also be added here and the details of the activity are listed in a table below the request.\\
\\
 Contains all requests sent by the user which are still ‘open’.
 Similar to Inbox features, except not allowed to cancel or complete request.
 If a request was created with a status of ‘Draft’, the creator of the request can change the status to New and send the request to the directed individual.
 Activities can also be added here and the details of the activity are listed in a table below the request.
At line 49 changed 2 lines
*Contains all requests sent or received by the user which have been completed or denied.
*This tab is a view only of the historical requests, therefore the user does not have the ability to modify the request or its activities.
 Contains all requests sent or received by the user which have been completed or denied.
 This tab is a view only of the historical requests, therefore the user does not have the ability to modify the request or its activities.
At line 52 changed 2 lines
!View All Requests
The View All Requests ([VERQ]) screen is a view of all requests which shows all open requests for a particular request type for all users in the system, not just the user currently signed in. This form would be used by the administrator.
At line 55 changed one line
!Form Toolbar Menu
VERQ – View All Requests
The View All Requests (VERQ) screen is a view of all requests which shows all open requests for a particular request type for all users in the system, not just the user currently signed in. This form would be used by the administrator.
Form Toolbar Menu
At line 57 changed 11 lines
*A menu labeled ‘Requests’ will appear on the form toolbar.
*This menu will appear on a form toolbar when there is at least one table defined in the form definition which also has a Request Type defined for it on [IMRT], otherwise the menu will not appear
*The menu items will have the basic request functions; ‘create new’, ‘view subject requests’ which open dialogs, and ‘view all’ which will open the [IERQ] screen
*The menu item will dynamically change based on which field (and parent table) has cursor focus; the menu will contain menu items for each request record that is tied to the current table and subject
*The number of relevant requests will display in the toolbar menu (e.g. if a subject has six open requests, and the user clicks on a field in that table, the menu will display ‘Requests (6)’. If there are no requests, then the menu will simply display ‘Requests’.)
*If cursor focus is on a field/table that does not have Request types, the ‘Create New’ request will not display in the menu drop down
*Roll up feature: The menu may show more requests than are on the current subject, for example, it will try to show all requests for the current subject and its parent. (e.g. if there are 2 requests on PTS and 3 requests on PTSE, then when cursor focus is on the PTS record, the menu will show ‘Requests (2)’, but when focus is on the PTSE record, the menu will show ‘Requests (5)’)
\\
----
!!Features of the Request Facility in Self Service
The Request functionality in Self Service is very similar to that in Personality. Users in Self Service will use the [WERQ] screen instead of the [IERQ] screen to review their outstanding requests or to create new requests. The only difference between these two forms is that the [WERQ] does not have the Context tab or Activities tab as Self Service at this time does not support the use of tabs within tabs. Other than that one difference, both forms have the same functionality. \\
 A menu labeled ‘Requests’ will appear on the form toolbar.
 This menu will appear on a form toolbar when there is at least one table defined in the form definition which also has a Request Type defined for it on IMRT, otherwise the menu will not appear
 The menu items will have the basic request functions; ‘create new’, ‘view subject requests’ which open dialogs, and ‘view all’ which will open the IERQ screen
 The menu item will dynamically change based on which field (and parent table) has cursor focus; the menu will contain menu items for each request record that is tied to the current table and subject
 The number of relevant requests will display in the toolbar menu (e.g. if a subject has 6 open requests, and the user clicks on a field in that table, the menu will display ‘Requests (6)’. If there are 0 requests, then the menu will simply display ‘Requests’.)
 If cursor focus is on a field/table that does not have Request types, the ‘Create New’ request will not display in the menu drop down
 Roll up feature: The menu may show more requests than are on the current subject, for example, it will try to show all requests for the current subject and its parent. (e.g. if there are 2 requests on PTS and 3 requests on PTSE, then when cursor focus is on the PTS record, the menu will show ‘Requests (2)’, but when focus is on the PTSE record, the menu will show ‘Requests (5)’)
The Requests menu toolbar:
At line 69 removed 2 lines
!Self Service Splash Menu
The Splash menu in Self Service displays the ‘Internal Requests I Need to Respond to’ menu item. This menu item will display on all of the roles associated to the user signed in. This menu item is the [VERQ_SPLASH] function which will display five new requests at a time, once the status changes from new it will be removed from this window.
At line 72 changed one line
The ‘Click Here To Access Your Requests’ link will direct the user signed into their [WERQ] screen where they can manage all of their outstanding and historical requests.
Create a New Request Dialog:
At line 74 changed 2 lines
!Self Service Form Toolbar Menu
Similar to the menu in Personality, the ‘View All My Requests’ menu item in the Self Service menu calls the [WERQ] screen (where as in Personality it calls [IERQ]). The other difference is that the shortcut keys do not appear in the Self Service menu as these are not supported in Self Service.
View Requests for this Subject Dialog:
At line 77 changed 9 lines
The dialogs are the same as those called from the menu in Personality.
\\
----
!!Setting up the Request Facility
Users can make use of the Request facility in its shipped capacity, however clients also have the ability to tailor the requests to meet their business needs.\\ \\
Clients can tailor the requests by the following:
*Creating new request types.
*Creating new embedded forms.
*Defining which request types require action and those that do not.
Context Requests Dialog:
Features of the Request Facility in Self Service
The Request functionality in Self Service is very similar to that in ePersonality. Users in Self Service will use the WERQ screen instead of the IERQ screen to review their outstanding requests or to create new requests. The only difference between these two forms is that the WERQ does not have the Context tab or Activities tab as Self Service at this time does not support the use of tabs within tabs. Other than that one difference, both forms have the same functionality.
Inbox Tab
At line 87 removed 2 lines
!Request Types
Requests are created using a pre-defined type defined in the Define Request Types ([IMRT]) screen. These types are defined for a specific base table in the database, meaning the requests can only be used in a form that calls that table. For example, the [ADD_PREMIUM] request type has been defined for the table, [P2K_PR_TIME_SHEETS]. A few example forms that call that particular table and that could use this request type are [IPTS], [IPMTS], [WAPTS], and [WEPTS].
At line 90 removed one line
New request types can be created for the same tables or different tables; however these must be created as User Defined. It is up to the administrator to decide which base tables should allow requests and then determine what types of requests are allowed for that table.
At line 92 removed 15 lines
Below is a list of pre-defined request types.
||Request Type||Table||Embedded Form
|ADD_EXPENSE| [P2K_PR_TIME_SHEETS]| [EPTS]
|ADD_PREMIUM| [P2K_PR_TIME_SHEETS]| [EPTS]
|ADD_TIME| [P2K_PR_TIME_SHEETS]| [EPTS]
|ADJUST_TIME| [P2K_PR_TIME_SHEETS]| [EPTS]
|CHANGE_LUNCH| [P2K_PR_TIME_SHEETS]| [EPTS]
|CURRENT_SPA| [P2K_SA_PERSONNEL_ACTIONS]| [ESPA]
|CURRENT_TS| [P2K_PR_TIME_SHEETS]| [EPTS]
|JOB_CHANGE| [P2K_PR_TIME_SHEETS]| [EPTS]
|LEAVE_REQUEST| [P2K_AT_LEAVE_LINES]|[EALR]
|OE EE QUESTIONS| [P2K_BE_OPEN_ENROLLMENT_EES]| [EBOEE]
|OE SUBMISSION| [P2K_BE_OPEN_ENROLLMENT_EES]| [EBOEE]
|PAST_TS| [P2K_PR_TIME_SHEETS]| [EPTS]
|REVIEW INFO| [P2K_SA_REVIEWS]| [ESRV]
At line 108 removed 2 lines
!Embedded Forms
[Embedded forms|EMBEDDED FORMS] are typically developed to provide a visual of the subject matter. These embedded forms can be linked to request types and approval processes. They provide a means of seeing crucial information without having the user jump back and forth between screens to see the details of the subject of the request or approval.
At line 111 removed 2 lines
*[Embedded forms|EMBEDDED FORMS] will be displayed in the Context tab in [IERQ] if they have been associated to a request type in [IMRT].
*The [embedded forms|EMBEDDED FORMS] will also display in [IDVAR] if they have been associated to an approval process via the Function Name field in [IDAP].
At line 115 removed 3 lines
!Requires Action
The client has the ability to determine which requests require action and which do not. If a request has been defined as requiring action it is up to the receiver to do something with the request.
At line 119 removed one line
If a request has been defined as not requiring action, the request is used more as a notation on a record for historical purposes.
At line 86 added 62 lines
Outbox Tab
Archived Tab
Self Service Splash Menu
The Splash menu in Self Service displays the ‘Internal Requests I Need to Respond to’ menu item. This menu item will display on all of the roles associated to the user signed in. This menu item is the VERQ_SPLASH function which will display 5 new requests at a time, once the status changes from new it will be removed from this window.
The ‘Click Here To Access Your Requests’ link will direct the user signed in to their WERQ screen where they can manage all of their outstanding and historical requests.
Self Service Form Toolbar Menu
Similar to the menu in ePersonality, the ‘View All My Requests’ menu item in the Self Service menu calls the WERQ screen (where as in ePersonality it calls IERQ). The other difference is that the shortcut keys do not appear in the Self Service menu as these are not supported in Self Service.
The dialogs are the same as those called from the menu in ePersonality.
Setting up the Request Facility
Users can make use of the Request facility in its shipped capacity, however clients also have the ability to tailor the requests to meet their business needs.
Clients can tailor the requests by the following:
 Creating new request types.
 Creating new embedded forms.
 Defining which request types require action and those that do not.
Request Types
Requests are created using a pre-defined type defined in the Define Request Types (IMRT) screen. These types are defined for a specific base table in the database, meaning the requests can only be used in a form that calls that table. For example, the ADD_PREMIUM request type has been defined for the table, P2K_PR_TIME_SHEETS. A few example forms that call that particular table and that could use this request type are IPTS, IPMTS, WAPTS, and WEPTS.
New request types can be created for the same tables or different tables; however these must be created as User Defined. It is up to the administrator to decide which base tables should allow requests and then determine what types of requests are allowed for that table.
Below is a list of pre-defined request types.
Request Type Table Embedded Form
ADD_EXPENSE P2K_PR_TIME_SHEETS EPTS
ADD_PREMIUM P2K_PR_TIME_SHEETS EPTS
ADD_TIME P2K_PR_TIME_SHEETS EPTS
ADJUST_TIME P2K_PR_TIME_SHEETS EPTS
CHANGE_LUNCH P2K_PR_TIME_SHEETS EPTS
CURRENT_SPA P2K_SA_PERSONNEL_ACTIONS ESPA
CURRENT_TS P2K_PR_TIME_SHEETS EPTS
JOB_CHANGE P2K_PR_TIME_SHEETS EPTS
LEAVE_REQUEST P2K_AT_LEAVE_LINES EALR
OE EE QUESTIONS P2K_BE_OPEN_ENROLLMENT_EES EBOEE
OE SUBMISSION P2K_BE_OPEN_ENROLLMENT_EES EBOEE
PAST_TS P2K_PR_TIME_SHEETS EPTS
REVIEW INFO P2K_SA_REVIEWS ESRV
Embedded Forms
Embedded forms are typically developed to provide a visual of the subject matter. These embedded forms can be linked to request types and approval processes. They provide a means of seeing crucial information without having the user jump back and forth between screens to see the details of the subject of the request or approval. Embedded forms can be created by clients as well; these should be created as User Defined.
 Embedded forms will be displayed in the Context tab in IERQ if they have been associated to a request type in IMRT.
 The embedded forms will also display in IDVAR if they have been associated to an approval process via the Function Name field in IDAP.
 Below is a list of provided embedded forms:
o EPTS – displays crucial time sheet information
o EALR – displays details of the requested leave and the employee’s current bank balance
o EBOEE – displays the employee’s open enrollment and their elections
o ESPA – displays personnel actions for an employee
o ESRV – displays an employee’s performance review
This is an example of the EALR embedded form:
Requires Action
The client has the ability to determine which requests require action and which do not. If a request has been defined as requiring action it is up to the receiver to do something with the request.
If a request has been defined as not requiring action, the request is used more as a notation on a record for historical purposes.
At line 123 removed 3 lines
----
![Notes|Edit:Internal.REQUEST FACILITY]
[{InsertPage page='Internal.REQUEST FACILITY' default='Click to create a new notes page'}]
This page (revision-13) was last changed on 26-Nov-2021 10:22 by JEscottTop