Results for “component_inventory_item_id”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

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:

• INCIDENT_NUMBER / INCIDENT_DATE — the user-visible service request identifier and creation date.
• INCIDENT_STATUS_ID, INCIDENT_TYPE_ID, INCIDENT_URGENCY_ID, INCIDENT_SEVERITY_ID — foreign keys that classify the request’s state and priority for escalation and SLA processing.
• SUMMARY, PROBLEM_DESCRIPTION, RESOLUTION_DESCRIPTION — core textual content describing the issue and its resolution.
• CUSTOMER_ID, ACCOUNT_ID, CUSTOMER_NUMBER, CUSTOMER_NAME — the requesting customer or party.
• INCIDENT_OWNER_ID, OWNER_GROUP_ID, RESPONSIBLE_GROUP_ID — assignment and ownership of the request.
• CUSTOMER_PRODUCT_ID, CURRENT_SERIAL_NUMBER, SYSTEM_ID — the installed base item or system to which the incident pertains.
• OPEN_FLAG, RECORD_IS_VALID_FLAG, CLOSE_DATE, ACTUAL_RESOLUTION_DATE — lifecycle state and closure tracking.
• ORG_ID — the multi-org operating unit context, essential for R12 data security.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY — standard EBS audit columns.

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:

• CS_INCIDENTS_EXT_B and CS_INCIDENTS_EXT — extended attribute storage keyed by INCIDENT_ID.
• CS_HZ_SR_CONTACT_POINTS — service request contacts (PRIMARY_CONTACT_ID, and referencing INCIDENT_ID back to this table).
• CS_SR_CONTACTS_EXT_B — additional contact details.
• CSD_REPAIRS, CSD_REPAIR_ORDER_GROUPS, and CS_ESTIMATE_DETAILS — depot repair and estimate lines associated with the incident.
• JTF_TASKS_B, JTF_NOTES_B, JTF_TASK_REFERENCES_B — CRM tasks, notes, and references pointing at the incident.
• CS_INCIDENT_LINKS — self-referencing links between incidents (FROM_INCIDENT_ID, OBJECT_ID, SUBJECT_ID).
• AHL_VISITS_B and AHL_UNIT_EFFECTIVITIES_B — field service visits and unit effectivity.
• CS_INCIDENT_STATUSES_B, CS_INCIDENT_TYPES_B, CS_INCIDENT_URGENCIES_B, CS_INCIDENT_SEVERITIES_B — the classification lookup tables referenced by the incident’s status and priority columns.

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.