Search Results cs_sr_contacts_ext_b




Overview
Explore in AI Chat

Overview

CS_SR_CONTACTS_EXT_B is a Service (CS) module table in the Oracle E-Business Suite, owned by the CS schema and documented as VALID in ETRM releases 12.1.1 and 12.2.2. Its stated purpose is to store Party Role Extensible Attribute records — that is, the externally-defined ("ext") descriptive flexfield-style attribute values captured against a party role that participates on a service request. Rather than holding a small, fixed set of typed business columns, the table acts as an attribute reservoir: a single row carries an identifier, a set of context keys, and a large bank of generic extension attribute columns that the customer's configuration has mapped to meaningful fields.

The physical definition contains 137 columns, dominated by the C_EXT_ATTRn, N_EXT_ATTRn, D_EXT_ATTRn, and UOM_EXT_ATTRn families, fifty of which are character-valued, twenty-five numeric, twenty-five date, and twenty-five unit-of-measure. Only four columns fall outside this extension bank: EXTENSION_ID, INCIDENT_ID, CONTEXT, and ATTR_GROUP_ID, plus the standard audit columns and the trailing PARTY_ID, CONTACT_TYPE, and PARTY_ROLE_CODE business identifiers. Under the heuristic Data Vault classification supplied in the metadata (satellite-leaning), the table is best modeled as a satellite hanging off an incident hub and the party/link structures that describe contact involvement, since its payload is descriptive and version-oriented rather than a set of independent business keys.

Key Information Stored

The most significant columns fall into three groups. The first is identity and context:

  • EXTENSION_ID — the surrogate primary key, enforced by CS_SR_CONTACTS_EXT_B_PK and also carried by the unique index CS_SR_CONTACTS_EXT_B_U1, which is the documented business-key candidate.
  • INCIDENT_ID — the foreign key to CS_INCIDENTS_ALL_B, tying the extension row to a specific service request.
  • CONTEXT — the descriptive flexfield context that determines which extension attributes are meaningful for the row.
  • ATTR_GROUP_ID — the attribute group or grouping identifier used to organize the extension values.
  • PARTY_ID, CONTACT_TYPE, and PARTY_ROLE_CODE — the party, contact type, and role that qualify which contact the extension row describes.

The second group is the standard Who columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN — which support auditing and incremental extraction. The third and largest group is the extension payload itself: fifty character attributes (C_EXT_ATTR1 through C_EXT_ATTR50), twenty-five numeric (N_EXT_ATTR1 through N_EXT_ATTR25), twenty-five date (D_EXT_ATTR1 through D_EXT_ATTR25), and twenty-five UOM (UOM_EXT_ATTR1 through UOM_EXT_ATTR25). Each is a generic container whose business meaning is established by the flexfield setup, so the same physical column can represent different concepts across contexts.

Common Use Cases and Queries

Typical usage centres on retrieving or reporting the extended contact detail captured against a service request, and on reconciling that detail with the party model. A common pattern joins the extension row to its parent incident:

  • Contact detail for one request: SELECT e.extension_id, e.incident_id, e.context, e.party_id, e.party_role_code, e.c_ext_attr1, e.n_ext_attr1, e.d_ext_attr1 FROM cs.cs_sr_contacts_ext_b e WHERE e.incident_id = :incident_id;
  • Resolution of a specific attribute by context: filter on CONTEXT and ATTR_GROUP_ID before reading the relevant *_EXT_ATTRn column, because the column's meaning is context-dependent.
  • Incremental extracts for a data warehouse: drive on LAST_UPDATE_DATE to capture only changed satellite rows, since the table is descriptive and version-oriented.
  • Audit and traceability: join CREATED_BY and LAST_UPDATED_BY to FND_USER to identify who entered or amended the extended contact data.

Because there is no documented unique constraint beyond EXTENSION_ID, queries intended to return one row per contact should aggregate or filter by context rather than assuming uniqueness on INCIDENT_ID plus PARTY_ID.

Related Objects

  • CS_INCIDENTS_ALL_B — the only documented foreign-key parent; joined via CS_SR_CONTACTS_EXT_B.INCIDENT_ID = CS_INCIDENTS_ALL_B.INCIDENT_ID, and the primary source of service request context for these extension rows.
  • CS_INCIDENTS_ALL_TL — the translated incident table, joined through CS_INCIDENTS_ALL_B to resolve request text alongside the extension attributes.
  • CS_SR_CONTACTS / CS_SR_CONTACTS_B — the base service request contact tables with which these extension rows align on incident and party.
  • HZ_PARTIES and HZ_PARTY_SITES — the Trading Community Architecture party tables resolved through PARTY_ID and PARTY_ROLE_CODE to name the contact and its role.
  • FND_USER — referenced by CREATED_BY, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN for audit reporting.
  • FND_DESCR_FLEX_CONTEXTS and the descriptive flexfield definition views — the configuration layer that determines the real-world meaning of each CONTEXT value and its mapped extension attribute columns.

Service request data is normally manipulated through the Service (CS) forms and the public APIs that operate on CS_INCIDENTS_ALL_B; direct DML against CS_SR_CONTACTS_EXT_B is not recommended outside controlled data-fix or migration scenarios.