Search Results cs_incidents_u2

Overview

CS.CS_INCIDENTS_ALL_B is the base (non-translatable) table in the Oracle E-Business Suite Service (CS) schema that stores service requests, also known as incidents. In a Release 12.1.1 or 12.2.2 environment it functions as the operational hub of the Service Request Management module. Each row represents a single service request, which may be logged against a product, a product held in inventory, or a product currently recorded in the install base.

The table is registered in FND Design Data as CS.CS_INCIDENTS_ALL_B, carries a VALID status, and resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. Because it supports multi-language operations, it holds only the non-translatable attributes; the corresponding translated columns are maintained separately and joined through the _ALL view layer. In a multi-organization deployment the table is partitioned by ORG_ID, which isolates records by operating unit and supports data security and performance at high volumes.

Applying a heuristic Data Vault classification, the object behaves as a hub: it is keyed by a single surrogate identifier, INCIDENT_ID, and is referenced by a large number of surrounding tables through foreign keys. This classification should be treated as a modeling suggestion rather than a documented property of the physical schema.

Key Information Stored

The physical schema documents 293 columns. The surrogate primary key is enforced by the CS_INCIDENTS_B_PK constraint on INCIDENT_ID and by the unique index CS_INCIDENTS_U1. Two additional unique indexes act as business-key candidates: CS_INCIDENTS_U2 on INCIDENT_NUMBER and CS_INCIDENTS_U3 on RMA_HEADER_ID — the latter being the index referenced in the user's search.

• INCIDENT_ID — surrogate primary key and the value propagated to all dependent tables.
• INCIDENT_NUMBER — externally visible service request number, enforced unique by CS_INCIDENTS_U2.
• INCIDENT_DATE and INCIDENT_STATUS_ID — when the request was logged and its current status, validated against CS_INCIDENT_STATUSES_B.
• INCIDENT_TYPE_ID, INCIDENT_URGENCY_ID, and INCIDENT_SEVERITY_ID — classification values sourced from the CS_INCIDENT_TYPES_B, CS_INCIDENT_URGENCIES_B, and CS_INCIDENT_SEVERITIES_B lookup tables.
• SUMMARY, PROBLEM_DESCRIPTION, and RESOLUTION_DESCRIPTION — free-text narrative fields describing the reported issue.
• INCIDENT_OWNER_ID, OWNER_GROUP_ID, and UNASSIGNED_INDICATOR — assignment and routing attributes.
• CUSTOMER_ID, ACCOUNT_ID, and CUSTOMER_NUMBER — the requesting party and account.
• CUSTOMER_PRODUCT_ID and CURRENT_SERIAL_NUMBER — the install base instance and serial number under service.
• INVENTORY_ITEM_ID and COMPONENT_INVENTORY_ITEM_ID — the product and component identifiers.
• RMA_HEADER_ID, RMA_NUMBER, and RMA_FLAG — return material authorization linkage.
• INCIDENT_LOCATION_ID and INSTALL_SITE_ID — physical and installation locations.
• ORG_ID — the operating unit, and the partition key.
• SECURITY_GROUP_ID — the data security group governing record visibility.
• CLOSE_DATE, PROBLEM_CODE, and RESOLUTION_CODE — closure timing and coded resolution outcomes.

Common Use Cases and Queries

Typical reporting includes aging of open service requests, workload distribution by owner or group, and analysis of resolution codes. A common pattern joins the base table to its translated counterpart through INCIDENT_ID, or filters on the unique business key. The following retrieves active requests for a given status and owner group:

SELECT c.incident_number, c.incident_date, c.summary, c.customer_id, c.expected_resolution_date FROM cs.cs_incidents_all_b c WHERE c.org_id = :org_id AND c.incident_status_id = :status_id AND c.owner_group_id = :group_id AND NVL(c.status_flag,'Y') = 'Y';

Because CS_INCIDENTS_U3 makes RMA_HEADER_ID unique, a request-to-RMA lookup is a highly selective access path: SELECT incident_number, rma_number FROM cs.cs_incidents_all_b WHERE rma_header_id = :rma_header_id. Index CS_INCIDENTS_N12 (CLOSE_DATE, EXPECTED_RESOLUTION_DATE) supports aging and overdue reporting, while CS_INCIDENTS_N16 on CREATION_DATE supports volume trending over time.

Related Objects

The table is heavily referenced. The most significant dependents and parents include:

• CS.CS_INCIDENTS_EXT_B — the extension table, joined on INCIDENT_ID, holding customer-defined attributes.
• CS.CS_INCIDENTS_AUDIT_B — the audit trail, joined on INCIDENT_ID.
• CS.CS_HZ_SR_CONTACT_POINTS — service request contact points, joined on INCIDENT_ID and referenced back through PRIMARY_CONTACT_ID.
• CS.CS_SYSTEM_SR_LINKS — links service requests to systems, joined on INCIDENT_ID.
• CS.CS_MESSAGES — threaded messages, joined via SOURCE_OBJECT_INT_ID.
• CS.CS_INCIDENT_LINKS — relationships between service requests, joined on OBJECT_ID and SUBJECT_ID.
• AHL.AHL_VISITS_B and AHL.AHL_VISIT_TASKS_B — field service visits, joined on SERVICE_REQUEST_ID.
• CSI.CSI_ITEM_INSTANCES — the install base instance referenced by CUSTOMER_PRODUCT_ID.
• HZ.HZ_PARTIES and HZ.HZ_CUST_ACCOUNTS — the customer and account, referenced by CUSTOMER_ID and ACCOUNT_ID.
• JTF.JTF_RS_RESOURCE_EXTNS — the resource referenced by INCIDENT_OWNER_ID.

These relationships confirm the object's role as the central service request hub within the Oracle EBS Service application.