Search Results problem_summary

Overview

XNS_SUPPORT_HISTORY_V is a reporting view that belongs to the XNS – Service for Communications product family within Oracle E-Business Suite. As documented in the ETRM metadata for releases 12.1.1 and 12.2.2, the view supplies "service request history for customer products in the installed base." Its purpose is to present a consolidated, denormalized read-only projection of service request (incident) activity, enriched with the descriptive names of the type, severity, status, and urgency attributes, together with owner, problem, and resolution information. Rather than exposing raw foreign-key identifiers, the view resolves coded values into human-readable text, making it suitable for end-user reporting, service analytics, and downstream integration extracts.

The product designation "obsolete" is significant: the ETRM documentation records that the view is "Not implemented in this database." Consequently, in a standard 12.1.1 or 12.2.2 installation the view may not physically exist unless the XNS module has been explicitly installed or customized. The view remains documented because it defines a supported interface contract for environments where the communications service history functionality was deployed.

Underlying Base Objects

The ETRM view text shows that XNS_SUPPORT_HISTORY_V is defined primarily over CS_INCIDENTS_ALL_VL, the multilingual service request (incident) table from the Service (CS) module. It joins this driving table to several reference views and tables:

• CS_INCIDENT_TYPES_VL — incident type descriptions.
• CS_INCIDENT_SEVERITIES_VL — incident severity descriptions.
• CS_INCIDENT_STATUSES_VL — incident status descriptions.
• CS_INCIDENT_URGENCIES_VL — incident urgency descriptions.
• PER_PEOPLE_X — the incident owner (person), joined with an outer join on INCIDENT_OWNER_ID.
• FND_LOOKUPS (L1 and L2) — lookup values for the problem code (LOOKUP_TYPE = 'REQUEST_PROBLEM_CODE') and resolution code (LOOKUP_TYPE = 'REQUEST_RESOLUTION_CODE').

The joins on severity, urgency, and the two lookup aliases are outer joins, so incidents lacking those optional attributes still appear. The joins on type and status are inner joins, meaning an incident must have a valid type and status to be returned. The view therefore inherits its transactional integrity and multilingual (VL) behavior directly from the underlying Service objects. It is not a base table and holds no data of its own.

Key Columns

• ROW_ID / INCIDENT_ID — unique identifiers for the incident record.
• INCIDENT_NUMBER — the user-facing service request number.
• CUSTOMER_PRODUCT_ID — links the history to the specific customer product in the installed base.
• INCIDENT_DATE / CLOSE_DATE — the opening and closing dates of the service request.
• INCIDENT_TYPE, SEVERITY, STATUS, URGENCY — decoded, descriptive attributes resolved from the CS reference views.
• OWNER — the full name of the person responsible for the incident.
• PROBLEM_SUMMARY / PROBLEM_DESCRIPTION — meaning and description from the REQUEST_PROBLEM_CODE lookup.
• RESOLUTION_DESCRIPTION — description from the REQUEST_RESOLUTION_CODE lookup.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns.

Common Use Cases and Queries

Typical applications include service-history reporting against an installed base, incident aging and closure analysis, and owner workload summaries. A representative query restricting to a single customer product follows:

• SELECT incident_number, incident_date, close_date, status, severity, owner, problem_summary, resolution_description FROM xns_support_history_v WHERE customer_product_id = :p_product_id ORDER BY incident_date DESC;
• SELECT incident_type, severity, COUNT(*) FROM xns_support_history_v GROUP BY incident_type, severity;
• SELECT owner, COUNT(*) FROM xns_support_history_v WHERE close_date IS NULL GROUP BY owner;

Because the ETRM metadata states the view is not implemented, SQL referencing it may raise ORA-00942 in default installations; verify its existence in the data dictionary before deploying reports that depend upon it.