This chapter covers the following topics:
In Oracle TeleService, the capture of electronic audit records (e-records) and electronic signatures (e-signatures) is triggered by the service request status (case status) field. Whenever an agent sets a service request (case) to a special status, the application captures the e-record and sends out any approval requests via the Oracle Workflow notification process. Approvers access these requests from the notification in their Inbox.
Here are two typical ways the integration can be used:
Use Case 1: Approval Before Work Can Begin
A medical equipment manufacturer requires sign-off before technicians can change the configuration of a particular piece of equipment such as an X-ray machine.
Use Case 2: Approval Before Closure
A manufacturing company requires special sign-off before service requests for safety violations can be closed.
Both these use cases are used to illustrate the setups in this chapter.
To implement this integration, you must set up:
Any approval rules using Oracle Approvals Management.
The templates for the e-record in Oracle E-Records.
Service request status and related setups as described in this chapter.
You must have both the Oracle Approvals Management and Oracle E-Records applications implemented before you begin. See Oracle HRMS Approvals Management Implementation Guide and Oracle E-Records Implementation Guide for details.
Note: The integration supports deferred-only approvals. It does not support online e-signature capture or e-signature capture via e-mail.
The e-record generated by the application serves both as a historical record of the service request and as the report, which is sent for approval. The application generates the e-record when the service request is set to the triggering status and updated. The content is based on a specific service Oracle E-Record template which has been seeded for this purpose.
The template (CSERecordTemplate.rtf) is an RTF document with embedded XML codes that pull in service request information. The template is set up to provide either a summary or a detailed report. For a listing of the attributes listed in each report and the differences between them see About the E-Record Template.
By default, the application generates the summary report to conserve system resources. You can modify the electronic record template to remove or add attributes or change its appearance. If you do, you must upload and register the new file using either Oracle XML Publisher or Oracle E-Records. For details, see Downloading and Registering the E-Record Template.
Your application provides the following single seeded event for use with Oracle Approvals Management:
Event name: Service Request Approval
Event Key: oracle.apps.cs.sr.ServiceRequestApproval
Online or Deferred: Deferred
This topic describes the special service application setups for the integration. These are:
The actual setup steps are outlined in Setting Up the Capture of Approvals and E-Records.
Note: You must be familiar with the terminology and function of various service request objects such as statuses, service request types, and related setups. See About Statuses, Status Groups, and Service Request Types.
An intermediate status is the status of the service request while it is waiting for the approval process to complete, an example is, "Waiting for Approval".
To create an intermediate status, you must select the Pending Approval check box while setting up the status in the Service Request Statuses page.
The application starts the approvals and e-record capture process you have implemented when an agent sets the service request to a triggering status.
If the Oracle Approvals Management rules you have set up determine that approval is required, then the application automatically sets the service request to the intermediate status (such as "Waiting for Approval") while it waits for the approval process to be completed.
If approval is not required, then the application resets the service request to the triggering status.
During setup, a status becomes a triggering status when you enter an intermediate status in the Intermediate Status field as you can see in the following image.
If your process generates an electronic record only (no approvals required), then you must still enter an intermediate status. However, as the e-record gets generated immediately when the service request is updated, the application never sets the service request to that intermediate status.
Note: A triggering status cannot be created as an initial status. This is because the application does not support approvals for service requests on creation.
Optionally, you can have the application set the service request to special statuses when the service request is approved or rejected. This is accomplished by making entries in the Rejection Action and Approval Action fields of the triggering status. You can make entries in one or both fields.
You want to specify an approval or rejection status if some action such as an escalation needs to happen as a result of the approval process outcome or if agents need to know if the particular service request was approved or not.
If you do not enter an approval status, the application sets the service request to the triggering status. For example, if the triggering status is "Closed" then the status becomes "Closed" after approval.
If the approval rules you have designed trigger the approval process only in certain cases (for certain products, for example), then without an approval status agents won't know if a service request was closed because it was approved or simply closed because no approval was necessary.
The following examples illustrate the different behavior with and without the approval status for a company that requires approval before service request closure (Use Case 2).
Approval Before Closure With Approval Action Status
Suppose you create the statuses listed in the following table for the approval process:
Status | Description |
---|---|
Open | Initial |
Closed | Triggering and Final |
Waiting for Approval | Intermediate |
Approved and Closed | Approval Action and Final |
Rejected | Rejection Action |
The application behaves as follows (numbers in brackets refer to the diagram below):
An agent wants to close the service request and so sets the service request status to Closed (1).
If an approval process is not triggered by the rules you set up, the service request remains Closed.
If approval is required, then the application sets the status to Waiting for Approval. (2)
If the service request is approved, then the application resets the service request status to Approved and Closed(3)
If it is rejected, then the status becomes Rejected.(4)
Note that the service request can end up in one of two final statuses: the triggering status "Closed" if no approval is required, or "Approved and Closed" if approval is required and obtained.
Approval Before Closure Without an Approval Action Status
To set service requests to the same "Closed" status regardless of any approval process, you can set up your statuses without the rejection action status:
Status | Description |
---|---|
Open | Initial |
Closed | Triggering and Final |
Waiting for Approval | Intermediate |
Rejected | Rejection Action |
Then the application behaves as follows:
The agent sets the service request status to Closed (1).
If your rules determine that service request does not requires any approval, the status remains Closed.
If approval is required, then the application sets the service request to Waiting for Approval (2).
If the service request is approved, the application resets the service request status back to Closed (3)
If it is rejected, the status gets set to Rejected.(4)
If you do not enter a rejection status, then the application reverts the service request to its previous status. If the agent had changed the service request from "Open" to the triggering status "Closed", a rejection resets the status to "Open". If you do not use a rejection status, then agents cannot tell that the service request was rejected without looking at the history log.
If your triggering status is not the final status and you want to ensure that all service requests are evaluated by your rules, you can set up status group transition rules to ensure that agents cannot bypass the triggering status.
Status groups determine the statuses that are available for a particular service request type. Their transition rules specify which status can be changed to which.
To prevent agents from manually setting the status to the Repair Rejected status, you must set up the following transition rules:
"New" to "Closed"
"New" to "Pending Approval"
"Pending Approval" to "Closed"
"Pending Approval" to "Rejected"
"Rejected" to "Closed" (if you want users to be able to resubmit)
Note that the above transition rules permit the transitions required by the approvals process as a whole not just those by the agent. Although the transitions permit the status to be changed from New to Pending Approval, the agents are prevented from making that status change by the transitions enforced by the approvals process itself.
You do not need to set up transition rules if:
Your triggering status is the service request's final status.
This is because all service requests must be closed and the triggering status enforces its own rules.
Agents decide on their own if the rules must be invoked.
A maker of medical devices that requires approvals for changes in equipment configuration may leave it up to agents to set the service request to the triggering status of "Repair" only if a unit needs servicing by a technician.
The status transition rules prevent agents from setting the service request to an intermediate status, but it does not prevent them from setting the service request to either the rejection action or the approval action statuses. You must set up status group transitions to prevent agents from using those statuses. For example, if you have the following statuses:
New Pending Approval (the intermediate status)
Repair Rejected (the Rejection Action)
Closed (the triggering status)
As there is no Approval Action status in this setup, the application sets the service request to Closed when approved. In this case, to prevent agents from manually setting the service requests to "Repair Rejected", you must set up the following transitions in the status group:
New to Closed
New to Pending Approval
Pending Approval to Closed
Pending Approval to Repair Rejected
If you want agents to resubmit after a rejection, then you must also include: Repair Rejected to Closed. See About Statuses, Status Groups, and Service Request Types.
Use this general procedure as a guide for setting up the Oracle E-Records and Oracle HRMS Approvals Management integration. Where applicable, each step provides a reference you can follow to obtain more details.
Prerequisites:
Implement Oracle E-Records as described in the Oracle E-Records Implementation Guide.
Implement Oracle Approvals Management as described in the Oracle HRMS Approvals Management Implementation Guide.
To set up the capture of approvals and e-records for a service request type
Plan out which statuses you need to set up.
Note: A simple example at the end of this topic illustrates the status and related setups for approvals before agents can close service requests (Use Case 2). See Example of Status and Related Setups.
Create the intermediate status. The procedure is similar to the procedure described in Setting Up Service Request Statuses. There is one additional step: for intermediate statuses you must select the Pending Approval check box. When you do, the application automatically selects the following check boxes:
Disallow Request Update
Prevents the service request from being updated while the service request is in the intermediate status.
On Hold
Placing a service request on hold prevents the application from distributing the service request to agents when they click the Get Next Work button while the service request is awaiting approval.
You can override the settings of both of these check boxes.
Note: Please note the following:
You cannot reuse the same intermediate status for multiple triggering statuses.
Agents cannot set service requests to the intermediate statuses themselves. The application does this automatically.
An intermediate status cannot be an initial status in the status group.
Optionally, create the rejection action and approval action statuses. This setup is the same as for general statuses.
Set up the trigger status. See Setting Up a Triggering Service Request Status.
Group the statuses into a status group using the procedure outlined in Setting Up Status Groups.
Optionally, set up the status transition rules for the status group. For details, see Status Groups and Status Transition Rules .
You must permit all the transitions required by your triggering status setup.
To have the application generate the detailed e-record report for your service request type rather than the default summary report, navigate to Setup, Definitions, HTML Setup, Service Request Types, and select the Detail ERES Record check box in the Process Configuration column.
If this check box is not selected, the default summary report is generated.
For more information about setting up service request types, see Setting Up Service Request Types.
Map the status group to the service request type.
See About Mapping Status Groups to Service Request Types and Responsibilities.
Optionally, modify the seeded electronic record (e-record) template and register the new version according to the procedures outlined in Downloading and Registering the E-Record Template.
You can add or remove information or modify the template's appearance. Oracle does not recommend extensive modifications. See About the E-Record Template for guidelines and a list of service request attributes used by the template.
Specify the variable EREC_STYLE_SHEET to the new template name you want to use for creating e-records.
If you require approvals:
Make sure you have set the variable ESIG_REQUIRED to Y.
Switch responsibility to Approvals Management Business Analyst.
Choose Service Request Approval as the Transaction Type to do your setup.
Set up the approval flow in Oracle Approvals Management according to the procedures described in the Oracle HRMS Approvals Management Implementation Guide. You can set up different approval rules based on parameters passed by the service request.
The following table lists the seeded service request parameters and the corresponding names used by the Oracle Approvals Management (OAM) user interface:
Service Request Parameter | OAM Name |
---|---|
Item | REQUEST_ITEM |
Item Category | REQUEST_CATEGORY |
Problem Code | REQUEST_PROBLEM_CODE |
Service Request Severity | REQUEST SEVERITY |
Service Request Status | REQUEST_STATUS |
Service Request Type | REQUEST_TYPE |
Service Request Urgency | REQUEST_URGENCY |
You can add any additional parameters from the detailed e-record template.
To have the application automatically capture approval information (including approver names, outcomes, and comments) as a note in the service request, you must set the system profile Service: Note Type for ERES Comment to any note type. By default, this system profile is null. This means the application does not capture the information in the service request. Users must instead go to the e-record to view it.
If you are capturing Oracle Quality data for the service request, then you must set up separate e-record capture and e-signature approval rules according to the procedures in Oracle E-Records Implementation Guide and the E-Records and E-Signatures for Oracle Quality section of the Oracle Quality User's Guide. The e-record capture and approval processes for service requests and Oracle Quality are independent. However, approvers and other users viewing the service request e-record can view the Oracle Quality e-record by following the link in the Related E-Records section.
This section uses an example to illustrate the status and related setups.
For example, if your company requires approvals from safety managers before agents can close service requests involving safety violations.
If the safety managers do not approve the solution, the service request must be escalated.
If the safety managers approve, the service request is closed automatically.
Here are the setup steps for this example:
Set up the statuses.
The triggering status is the final status: "Closed".
Because you want to escalate service requests when they are rejected, you need a rejection action status.
You do not need to set up an approval action status as you want the application to set the service request in the Closed status if approval is obtained or no approval is required.
The statuses you need are the same as those described in Approval Before Closure Without an Approval Action Status. Additional details about entries you must make in the status setup window are shown in the table below:
Status | Initial Check Box | Final Check Box | On Hold Check Box | Intermediate Status Field | Rejection Action Field | Approval Action Field | Pending Approval Check box | Disallow Request Update Check Box |
---|---|---|---|---|---|---|---|---|
Open | Selected | Null | Null | Null | Null | Null | Null | Null |
Closed | Null | Selected | Selected | Waiting for Approval | Rejected | Approved | Null | Null |
Waiting for Approval | Null | Null | Selected | Null | Null | Null | Selected | Selected |
Rejected | Null | Null | Selected | Null | Null | Null | Null | Selected |
Please note that:
Open is the initial status
Closed is the triggering status.
Waiting for Approval is the intermediate status.
Selecting the On Hold check box prevents the application from reassigning the service request
Selecting the Disallow Request Update check box prevents agents form updating the service request.
Group the statuses by creating a service request status group called "Safety Complaint Group," for example. The following table shows the setup:
SR Status Group | Statuses |
---|---|
Safety Complaint Group | Open, Closed, Waiting for Approval, Rejected |
You must set up status transition rules to prevent agents from setting the service request to the approval action and rejection action statuses.
Because you have only one status group for all users in this example, you can associate the status group with the service request type on the Service Request Type setup window as shown in the table below:
Service Request Type | Status Group |
---|---|
Safety Compliant | Safety Complaint Group |
Use this procedure to set up service request statuses that trigger the Oracle E-Record processes you have set up.
Prerequisites:
You must set up the intermediate, rejection action, and approval action statuses.
To set up a triggering service request status
Navigate to the Service responsibility, Setup, Definitions, HTML Setup, and then Service Request Statuses.
The Service Request Statuses page appears.
Enter a name in the Status field. This is what the agent sees when the application sets the service request to this status.
Enter an intermediate status using the Intermediate status list of values. If the Oracle E-Record process you have set up requires approvals (e-signatures), then the service request will be set to this status until all the approvals are obtained. If approvals are not required, then the service request remains in the triggering status.
If approvals are required, then select the Approval Action status and the Rejection Action status.
To assign a color to the text the support agent sees in the Status field of the Service Request page use the Text Color field.
You can use Oracle XML Publisher to download the seeded template for modification. After modification you must rename and upload the new template file and specify it as the default.
For details on using Oracle XML Publisher, see the Oracle XML Publisher Report Designer's Guide.
Use these guidelines for downloading the seeded template for modification and uploading the new version.
To download or register the template using Oracle XML Publisher
Under the XML Publisher Administrator responsibility navigate to Home, Templates.
The XML Publisher Templates page appears.
To display the seeded template, search for "Service" in the Application field and "RTF" as the Type.
Click the "Service Request E-Record" link in the Name field.
Note: Your application includes two other templates, which are used for service request reports.
The View Template: Service Request E-Record page appears.
To download the template for modification, click Download.
If you modify the seeded template, you must upload it under a different name and then make it the default.
Click Update and enter the file name (Code) in the Default File field in the Update Template Definition page.
You must set Oracle E-Record variables using this procedure to specify a modified e-record template you have uploaded to Oracle XML Publisher or if you want to capture e-signature without requiring approval.
Prerequisites:
You must first upload and register the template you want to use for capturing the e-record.
To set Oracle E-Record Variables
Under the ERES Administrator responsibility, navigate to Administration Tasks, Setup.
The Configuration Variables page opens in a browser window.
Using the Search field search for Service Request Approval.
Modify the values of the service request variables as shown in the table below:
Variable Name | Name | Description |
---|---|---|
EREC_REQUIRED | E-Record Required | You must set this variable to Y to capture e-records and e-signatures. A setting of N disables both e-records and e-signatures. |
EREC_STYLE_SHEET | E-Record Style Sheet | Set this variable to the name of the e-record template you want to use. By default, the value is set to the seeded template CSERecordTemplate_en_US.rtf. |
ESIG_REQUIRED | E-Signature Required | Set to Y (the default) if approvals are required. Set to N to capture the e-record only. |
Agents can view the status of pending approvals for individual service requests by clicking the E-Records Detail link from their service request. However, you can use this procedure to view the status of approval processes for all service requests.
To view the status of approval requests
Log in under the ERES Administrator responsibility.
Navigate to Evidence Store.
The E-record Details page appears.
The event name to use for your search is: oracle.apps.cs.sr.ServiceRequestApproval.
This section provides guidelines for modifying the predefined e-record template and lists all the service request related information in both the summary and detailed report.
Because the template includes logic to generate both the summary and detailed report and because it is tied to the service request type setup, Oracle suggests you keep modifications to a minimum.
You can:
Delete fields from the template
Change template name provided you register the new file with Oracle XML Publisher or Oracle E-Records. See Downloading and Registering the E-Record Template.
Alter layout or graphics
Move or add fields
You can add or move fields if they are from the same report. For example, you can move Incident Address, which displays only in the detailed report to another place in the detailed report, but you cannot add it to the summary report.
What you must not do:
Move or add fields from the summary report to the detailed report or vice versa.
Delete logic in the template
The sections below list the service request attributes displayed in the summary and the detailed reports and any additional attributes you can add. The sections correspond to the sections in the report itself.
Each table lists the service request attribute and its XML data element.
This section lists the service request attributes and their XML data elements used for the detailed report.
The following table lists the service request customer attributes used by the detailed report. There are no additional customer attributes available for inclusion in the report.
Attribute | XML Data Element |
---|---|
Account | ACCOUNT_NUMBER |
Name | CUSTOMER_NAME |
Number | CUSTOMER_NUMBER |
Type | CUSTOMER_TYPE |
The following table lists the service request primary contact information displayed in the detailed report.
Attribute | XML Data Element |
---|---|
CONTACT_EMAIL | |
Name (Concatenation of title, first, and last name) |
CONTACT_NAME |
Phone Number | CONTACT_PHONE_NUMBER |
Phone Type | CONTACT_TELEPHONE_TYPE |
Type | CONTACT_TYPE |
The following table lists the service request problem information displayed in the detailed report. This appears under the heading, Subject.
Attribute | XML Data Element |
---|---|
Category | ITEM_CATEGORY |
Incident Address | INCIDENT_ADDRESS |
Item Description | PRODUCT_DESCRIPTION |
Item Instance | INSTANCE_NUMBER |
Item Number | PRODUCT |
Problem Code | PROBLEM_CODE |
Problem Summary | PROBLEM_SUMMARY |
Resolution Code | RESOLUTION_CODE |
Resolution Summary | RESOLUTION_SUMMARY |
Serial Number | SERIAL_NUMBER |
The following table lists the service request information displayed in the detailed report under the heading, Request.
Attribute | XML Data Element |
---|---|
Escalation Level | ESCALATION_LEVEL |
Group | SR_GROUP |
Incident Date | INCIDENT_DATE |
Owner | SR_OWNER |
Owner Type | RESOURCE_TYPE |
Reported Date | REPORTED_DATE |
Resolve By Date | RESOLVE_BY_DATE |
Resolved On Date | INCIDENT_RESOLVED_DATE |
Respond By Date | RESPOND_BY_DATE |
Responded On Date | INC_RESPONDED_BY_DATE |
Severity | INCIDENT_SEVERITY |
Status | INCIDENT_STATUS |
Type | INCIDENT_TYPE |
Urgency | INCIDENT_URGENCY |
The following table lists the service contract information displayed in the detailed report under the heading, Contract.
Attribute | XML Data Element |
---|---|
Coverage (Name of coverage for the service line in the contract) |
CONTRACT_COVERAGE |
Number (Service Contract Number) |
CONTRACT_NUMBER |
Service (Name of service in contract line) |
CONTRACT_SERVICE |
The following table lists the service request task information displayed in the detailed report under the heading, Task.
Attribute | XML Data Element |
---|---|
Actual Effort | TASK_ACTUAL_EFFORT |
Actual End Date | TASK_ACTUAL_END_DATE |
Actual Start Date | TASK_ACTUAL_START_DATE |
Creation Date | TASK_CREATION_DATE |
Description | TASK_DESCRIPTION |
Duration | TASK_DURATION |
Number | TASK_NUMBER |
Owner | TASK_OWNER |
Owner Type | TASK_OWNER_TYPE |
Parent | TASK_PARENT_TASK_NUMBER |
Planned Effort | TASK_PLANNED_EFFORT |
Planned End Date | TASK_PLANNED_END_DATE |
Planned Start Date | TASK_PLANNED_START_DATE |
Priority | TASK_PRIORITY |
Scheduled End Date | TASK_SCHEDULED_END_DATE |
Scheduled Start Date | TASK_SCHEDULED_START_DATE |
Status | TASK_STATUS |
Subject | TASK_NAME |
Type | TASK_TYPE |
Unit of Measure for Actual Effort | TASK_ACTUAL_EFFORT_UOM |
Unit of Measure for Duration | TASK_DURATION_UOM |
Unit of Measure for Planned Effort | TASK_PLANNED_UOM |
The following table lists the notes information displayed in the detailed report under the heading, Notes.
Attribute | XML Data Element |
---|---|
Created By | NOTE_CREATED_BY |
Date Entered | NOTE_CREATION_DATE |
Description | NOTE_DESCRIPTION |
Detail | NOTE_DETAIL |
Type | NOTE_TYPE |
Visibility | NOTE_VISIBILITY |
The following table lists information about related service requests displayed in the detailed report under the heading, Related Service Requests.
Attribute | XML Data Element |
---|---|
Number | RELATEDSR_NUMBER |
Owner | RELATEDSR_OWNER |
Relationship | RELATEDSR_NAME |
Severity | RELATEDSR_SEVERITY |
Status | RELATEDSR_STATUS |
Summary | RELATEDSR_SUMMARY |
The following table lists the related objects information displayed in the detailed report.
Attribute | XML Data Element |
---|---|
Description | RELATEDOB_DESCRIPTION |
Number | RELATEDOB_NUMBER |
Object | RELATEDOB_NAME |
The Service Request Additional Information section of the XML reports lists the information you enter in the descriptive flexfield located on the Workbench tab of the Service Request window.
If you have implemented the capture of additional service request information using this flexfield, you must modify the prompts in the report to correspond to the prompts in the flexfield. The prompts and the corresponding XML data elements are listed in the table below:
Prompt | Corresponding XML Data Element |
---|---|
Attribute 1 Prompt | ATTRIBUTE1 |
Attribute 2 Prompt | ATTRIBUTE2 |
Attribute 3 Prompt | ATTRIBUTE3 |
Attribute 4 Prompt | ATTRIBUTE4 |
Attribute 5 Prompt | ATTRIBUTE5 |
Attribute 6 Prompt | ATTRIBUTE6 |
Attribute 7 Prompt | ATTRIBUTE7 |
Attribute 8 Prompt | ATTRIBUTE8 |
Attribute 9 Prompt | ATTRIBUTE9 |
Attribute 10 Prompt | ATTRIBUTE10 |
Attribute 11 Prompt | ATTRIBUTE11 |
Attribute 12 Prompt | ATTRIBUTE12 |
Attribute 13 Prompt | ATTRIBUTE13 |
Attribute 14 Prompt | ATTRIBUTE14 |
Attribute 15 Prompt | ATTRIBUTE15 |
Context Prompt | INCIDENT_CONTEXT |
The Service Request External Additional Information section of the report lists the information captured by the flexfield in the header of the Service Request window.
If you have implemented this flexfield, you must modify the attribute prompt in the report to correspond to the prompts in your flexfield. The table below lists the seeded prompts.
Prompt | Corresponding XML Data Element |
---|---|
Ext Attribute 1 Prompt | EXT_ATTRIBUTE1 |
Ext Attribute 2 Prompt | EXT_ATTRIBUTE2 |
Ext Attribute 3 Prompt | EXT_ATTRIBUTE3 |
Ext Attribute 4 Prompt | EXT_ATTRIBUTE4 |
Ext Attribute 5 Prompt | EXT_ATTRIBUTE5 |
Ext Attribute 6 Prompt | EXT_ATTRIBUTE6 |
Ext Attribute 7 Prompt | EXT_ATTRIBUTE7 |
Ext Attribute 8 Prompt | EXT_ATTRIBUTE8 |
Ext Attribute 9 Prompt | EXT_ATTRIBUTE9 |
Ext Attribute 10 Prompt | EXT_ATTRIBUTE10 |
Ext Attribute 11 Prompt | EXT_ATTRIBUTE11 |
Ext Attribute 12 Prompt | EXT_ATTRIBUTE12 |
Ext Attribute 13 Prompt | EXT_ATTRIBUTE13 |
Ext Attribute 14 Prompt | EXT_ATTRIBUTE14 |
Ext Attribute 15 Prompt | EXT_ATTRIBUTE15 |
Ext Context Prompt | EXT_CONTEXT |
The information in the following table is listed under the heading, Service Request Extensible Attributes.
Attribute | XML Data Element |
---|---|
Attribute Group Name | ATTR_GROUP_DISP_NAME |
Attribute Value | ATTR_VALUE_DISPLAY |
Attribute Group (Internal Name) |
GROUP |
Attribute Unit of Measure | ATTR_UNIT_OF_MEASURE |
You can add additional XML data elements listed in the table below to the detailed report:
XML Data Element | Attribute Description |
---|---|
ACCOUNT_ID | Application-Generated ID Number |
ACTUAL_RESOLUTION_DATE | Resolved On Date |
CLOSE_DATE | Date Request Was Closed |
COMPONENT | Oracle Installed Base or Inventory Component Number |
COMPONENT_REVISION | Oracle Installed Base or Inventory Component Revision Number |
CONTACT_PARTY_ID | Application-Generated ID Number |
CREATED_BY | Created by |
CREATED_BY_ID | Application-Generated ID Number |
CUSTOMER_EMAIL | Customer's Primary E-Mail Address |
CUSTOMER_ID | Application-Generated ID Number |
CUSTOMER_PHONE | Customer's Primary Phone Number |
CUSTOMER_PRODUCT_ID | Application-Generated ID Number |
INCIDENT_ID | Application-Generated ID Number |
INCIDENT_SERVERITY_ID | Application-Generated ID Number |
INCIDENT_STATUS_ID | Application-Generated ID Number |
INCIDENT_TYPE_ID | Application-Generated ID Number |
INCIDENT_URGENCY_ID | Application-Generated ID Number |
INVENTORY_ORG_ID | Application-Generated ID Number |
INVERTORY_ITEM_ID | Application-Generated ID Number |
ITEM_REVISION | Oracle Installed Base or Inventory Item Revision Number |
LAST_UPDATE_DATE | Date of Last Service Request Update |
ORGANIZATION_ID | Application-Generated ID Number |
ORGANIZATION_ID | Application-Generated ID Number |
PROBLEM_CODE_ID | Application-Generated ID Number |
PUBLISH_FLAG | Publish Flag for the Service Request (This flag, which can have a value of Y or N, determines if customers can view the service request on their Oracle iSupport Web portal.) |
RESOLUTION_CODE_ID | Application-Generated ID Number |
SEV_IMPORTANCE_LEVEL | Severity Importance Level |
SR_CREATION_CHANNEL | Service Request Creation Channel |
SR_GROUP_ID | Application-Generated ID Number |
SR_OWNER_ID | Application-Generated ID Number |
STATUS_FLAG_CODE | Application-Generated ID Number |
STATUS_SORT_ORDER | Application-Generated ID Number |
SUB_COMPONENT | Oracle Installed Base or Inventory Subcomponent Number |
SUB_COMPONENT_REVISION | Oracle Installed Base or Inventory Subcomponent Revision Number |
SYSTEM_NUMBER | Oracle Installed Base System Number |
TAG_NUMBER | Oracle Installed Base Tag Number |
TIMEZONE_ID | Application-Generated ID Number |
TIMEZONE_NAME | Contact's Time Zone (Contact time zone name from the CS schema.) |
The tables in this section list the attributes captured by the summary e-record and their corresponding XML data elements.
The following table lists the service request problem information displayed in the summary report. This appears under the heading, Subject.
Attribute | XML Data Element |
---|---|
Problem Summary | PROBLEM_SUMMARY |
Resolution Summary | RESOLUTION_SUMMARY |
The following table lists the service request information displayed in the summary report under the heading, Request.
Attribute | XML Data Element |
---|---|
Severity | INCIDENT_SEVERITY |
Status | INCIDENT_STATUS |
Type | INCIDENT_TYPE |
You can add additional XML data elements listed in the table below to the summary report:
Attribute | XML Data Element |
---|---|
Problem Code | PROBLEM_CODE |
Resolution Code | RESOLUTION_CODE |
Severity Importance Level | SEV_IMPORTANCE_LEVEL |
For all date fields in an electronic record, the application uses either the server time zone or the time zone selected by the application user (client time zone) depending on the setting of system profile Enable Timezone Conversions.
If Enable Timezone Conversions profile is set to Y, the application uses the user preferred time zone. If the profile is set to N, it uses the system time zone.
The following fields are affected:
Reported Date
Incident Date
Respond By Date
Resolve By Date
Responded On Date
Resolved On Date
Task Creation Date
Task Planned Start Date
Task Planned End Date
Task Scheduled Start Date
Task Scheduled End Date
Task Actual Start Date
Task Actual End Date
Note Creation Date
The application stamps the top of each electronic record with the time zone, the date, and the time the record was generated.