Search Results problem_code_description

Overview

The view XNS_INCIDENTS_WORKFLOW_V belongs to the XNS – Service for Communications product family, which is documented in Oracle ETRM as obsolete. Its stated purpose is to expose service requests (incidents) together with their descriptive attributes for consumption by the Communications workflow. The view provides a denormalized, workflow-oriented projection of service request records, joining the incident header to its type, severity, status, urgency, owner, customer, product, and lookup-based problem and resolution codes, and resolving the creating user to a login name.

The column EXPECTED_RESOLUTION_DATE, which is the likely target of a user searching this object, is sourced directly from the base service request table and represents the target or committed resolution date for the incident. Because the view is not implemented in the reference database and is marked obsolete in 12.1.1 and 12.2.2, it should be treated as a legacy integration artifact rather than a supported reporting interface. Implementations still referencing it will generally be found in older Communications or TeleService-related workflow customizations.

Underlying Base Objects

The ETRM metadata records no documented referenced base objects, indicating the view is not implemented in the shipped database. The view text nevertheless defines its dependencies explicitly. It is constructed over the following base objects:

• CS_INCIDENTS_ALL_VL — the service request header, aliased INC, supplying the incident number, summary, dates, owner, codes, and customer and inventory references.
• CS_INCIDENT_TYPES_VL, CS_INCIDENT_SEVERITIES_VL, CS_INCIDENT_STATUSES_VL, CS_INCIDENT_URGENCIES_VL — lookup views providing the descriptive names for type, severity, status, and urgency.
• CS_SR_OWNERS_V and JTF_RS_RESOURCE_EXTNS — the owner resource and the associated resource identifier.
• HZ_PARTIES — the customer party name.
• CS_CUSTOMER_PRODUCTS, MTL_SYSTEM_ITEMS_VL, and the CS_STD.GET_ITEM_VALDN_ORGZN_ID function — product and inventory item context.
• FND_LOOKUPS (two aliases) — meanings and descriptions for problem and resolution codes.
• FND_USER — the name of the user who logged the request.

Nearly all joins to the descriptive objects are outer joins, so incidents survive even where severity, urgency, customer, or product data is absent.

Key Columns

• INCIDENT_ID, INCIDENT_NUMBER, SUMMARY — primary identifier and descriptive text of the service request.
• EXPECTED_RESOLUTION_DATE — the committed target date for resolving the incident; a primary driver for workflow escalation and aging logic.
• INCIDENT_DATE — the date the incident was raised.
• INCIDENT_OWNER_ID, OWNER — the assigned resource identifier and resource name.
• INCIDENT_TYPE, SEVERITY, STATUS_CODE, URGENCY — decoded classification and state values.
• PROBLEM_CODE, RESOLUTION_CODE with their _MEANING and _DESCRIPTION companions — coded diagnosis and closure information.
• CUSTOMER_NAME, CUSTOMER_PRODUCT_ID, PRODUCT_DESCRIPTION, INVENTORY_ITEM_ID — customer and product context.
• LOGGED_BY_NAME — the FND user who created the incident.

Common Use Cases and Queries

The view was intended for workflow routing and notification, where a Communications workflow needed a single row containing all classification, ownership, and resolution-date attributes. Typical queries retrieve incidents approaching or past their expected resolution date:

• Filter on EXPECTED_RESOLUTION_DATE to drive escalation or aging reports.
• Group by OWNER, SEVERITY, or STATUS_CODE to assess workload or bottlenecks.
• Join results to FND or HR data using INCIDENT_OWNER_ID for routing decisions.

A representative query is:

SELECT INCIDENT_NUMBER, SUMMARY, OWNER, SEVERITY, STATUS_CODE, EXPECTED_RESOLUTION_DATE
FROM XNS_INCIDENTS_WORKFLOW_V
WHERE TRUNC(EXPECTED_RESOLUTION_DATE) <= TRUNC(SYSDATE)
AND STATUS_CODE NOT IN ('Closed', 'Cancelled');

Because the object is obsolete and absent from the database in current 12.2.2 environments, equivalent reporting should be built directly against CS_INCIDENTS_ALL_VL and the associated CS lookup views.