Search Results customer_phone_id




Overview

CS_INCIDENTS_ALL_B is the base (non-translated) table in the Oracle E-Business Suite Service (CS) module that stores service requests — historically and still internally referred to as "incidents." In EBS 12.1.1 and 12.2.2 this table is owned by the CS schema and serves as the central repository for the descriptive, lifecycle, and relationship data of every service request created or imported into the system. Because all language-independent attributes are held here, translatable descriptive text is split off into a companion _TL table, while this _B suffix table remains the authoritative record of each incident.

From a dimensional-modeling perspective, the metadata’s heuristic Data Vault classification places CS_INCIDENTS_ALL_B as a hub. This is a modeling suggestion only: the table carries a clean surrogate primary key (INCIDENT_ID) with multiple business-key candidates and is referenced as the target of an extensive set of foreign keys from other tables. The documented physical schema contains 293 columns, reflecting the maturity of the Service module and the many optional service-request attributes it supports.

Key Information Stored

The table is anchored by the surrogate primary key INCIDENT_ID (constraint CS_INCIDENTS_B_PK) and two additional unique indexes that represent natural business keys: INCIDENT_NUMBER (CS_INCIDENTS_U2) and RMA_HEADER_ID (CS_INCIDENTS_U3).

The most operationally significant columns include:

Common Use Cases and Queries

The most frequent reporting pattern joins CS_INCIDENTS_ALL_B to its status and type lookup tables to produce open-incident dashboards. A typical query aggregates open requests by status:

  • SELECT i.incident_number, i.summary, s.name status, i.incident_date FROM cs_incidents_all_b i, cs_incident_statuses_b s WHERE i.incident_status_id = s.incident_status_id AND i.open_flag = 'Y' AND i.org_id = :org_id;
  • Aging and SLA analysis uses OBLIGATION_DATE, EXPECTED_RESOLUTION_DATE, and CLOSE_DATE against the SLA_DATE_n and SLA_DURATION_n columns.
  • Customer-facing extracts join to HZ_PARTIES and HZ_CUST_ACCOUNTS via CUSTOMER_ID and ACCOUNT_ID.
  • Installed-base analysis joins to CSI_ITEM_INSTANCES through CUSTOMER_PRODUCT_ID to correlate incidents with specific serialized assets.
  • Assignment/queue reporting joins to JTF_RS_RESOURCE_EXTNS, JTF_RS_GROUPS_B, and JTF_RS_TEAMS_B through INCIDENT_OWNER_ID.

Related Objects

The referential network is extensive. The most significant dependents and parents include:

These dependencies confirm CS_INCIDENTS_ALL_B as the hub of the Service module’s transactional data model, with downstream repair, task, contact, and field-service tables all resolving back to a single INCIDENT_ID.