Search Results record_is_valid_flag

Overview

XNS_INCIDENTS_V is a database view historically associated with the XNS – Service for Communications product, a module in Oracle E-Business Suite that has since been designated obsolete. The view presents service requests (incidents) together with their descriptive attributes, consolidating incident header data, foreign-key resolved lookup values, and customer product context into a single queryable object. The ETRM documentation describes it succinctly as "Service requests and their attributes," which reflects its role as a denormalized reporting surface over the incident entity.

In EBS 12.1.1 and 12.2.2, the view is documented as not implemented in this database. This indicates that XNS_INCIDENTS_V exists only in installations where the XNS Service for Communications module was licensed and deployed, and that it is absent from a standard EBS instance. Consequently, references to it in reports, concurrent programs, or custom SQL will fail with an ORA-00942 error on databases where the XNS schema objects were never created. The user search term "resource_subtype_id" maps directly to the INC.RESOURCE_SUBTYPE_ID column exposed by the view, which categorizes the resource associated with an incident in conjunction with INC.RESOURCE_TYPE.

Underlying Base Objects

The ETRM metadata documents no referenced base objects for this view. However, the embedded view text reveals that XNS_INCIDENTS_V is defined over an incident base table, aliased INC, joined to several lookup and reference tables. The lookup joins resolve identifiers into human-readable names: INCIDENT_TYPE uses a table aliased TYPE, INCIDENT_SEVERITY_ID uses SEV, INCIDENT_STATUS_ID uses STATUS, and INCIDENT_URGENCY_ID uses URGENCY. User identity is resolved through FND_USER for CREATED_BY_NAME and through a second FND user or employee source aliased FND2 for EMPLOYEE_NAME and EMPLOYEE_NUMBER. Customer product context is supplied by a table aliased CP joined to CPS and SYS, providing serial number, system name, reference number, and customer product status. Because the metadata documents no base objects and the module is obsolete, DBAs should confirm actual dependencies by querying ALL_DEPENDENCIES for the view before relying on any structural assumption.

Key Columns

• INCIDENT_ID, INCIDENT_NUMBER – Primary identifier and the user-facing service request number; INCIDENT_NUMBER_N is a duplicate alias of the same value.
• RESOURCE_TYPE, RESOURCE_SUBTYPE_ID – Classify the resource against which the incident is filed; RESOURCE_SUBTYPE_ID is the specific subtype referenced by the user's search.
• INCIDENT_STATUS_ID, STATUS_CODE – Status identifier and its resolved name.
• INCIDENT_TYPE_ID, INCIDENT_TYPE – Incident classification and resolved type name.
• SEVERITY, URGENCY – Resolved severity and urgency names.
• SUMMARY – Text summary of the service request.
• INVENTORY_ITEM_ID, CUSTOMER_PRODUCT_ID, CURRENT_SERIAL_NUMBER, SYSTEM_ID, SYSTEM_NAME – Product and installed-base context.
• SHIP_TO_SITE_USE_ID, BILL_TO_SITE_USE_ID, INSTALL_SITE_USE_ID – Site use references for shipping, billing, and installation.
• INCIDENT_DATE, EXPECTED_RESOLUTION_DATE, ACTUAL_RESOLUTION_DATE – Lifecycle dates.
• ORG_ID – Multi-org operating unit identifier.
• INCIDENT_ATTRIBUTE_1 through INCIDENT_ATTRIBUTE_15 – Descriptive flexfield segments.

Common Use Cases and Queries

Typical use cases include service request reporting by resource subtype, installed-base analysis, and aging of unresolved incidents. A representative query filtered on the searched column is:

SELECT incident_number, resource_type, resource_subtype_id, status_code, summary FROM xns_incidents_v WHERE resource_subtype_id = :p_subtype AND org_id = :p_org;

A second pattern joins the view to inventory or customer master data to report incidents by product serial number. Because the view is documented as unimplemented in standard 12.1.1 and 12.2.2 databases, any such query must be preceded by an existence check against ALL_VIEWS. Where the view is unavailable, equivalent reporting should be sourced from the Service (CS) module incident tables, which provide comparable service request attributes and remain supported.