Search Results pending_approval_flag

Overview

CS_INCIDENT_STATUSES_B is the base (non-translated) definition table for Service Request statuses in the Oracle E-Business Suite Service (CS) module. It resides in the CS schema and holds the canonical, language-independent attributes of every status that a Service Request (incident) can assume, such as Open, Working, Pending, Resolved, and Closed. The translated display names and descriptions are not stored here; they are maintained in the companion table CS_INCIDENT_STATUSES_TL, which joins back to this table on INCIDENT_STATUS_ID. This separation allows a single status definition to be presented in multiple languages while preserving one physical row per status.

The table functions as the control point for Service Request lifecycle behavior. Flags such as CLOSE_FLAG, RESOLVED_FLAG, ON_HOLD_FLAG, and PENDING_APPROVAL_FLAG determine how the application treats an incident at a given status, while the DISALLOW_* columns govern which actions users may perform. Because these rules are enforced application-wide, the table is central to status-driven workflow, action control, and reporting across the Service module.

The provided metadata classifies the object as hub-leaning under a Data Vault heuristic. In that modeling view, CS_INCIDENT_STATUSES_B would serve as a hub, with its INCIDENT_STATUS_ID acting as the durable business key, and dependent fact or satellite tables carrying time-variant or descriptive attributes. This is a modeling suggestion rather than a physical design statement.

Key Information Stored

The surrogate primary key is INCIDENT_STATUS_ID, enforced by the CS_INCIDENT_STATUSES_B_PK constraint. A separate unique index, CS_INCIDENT_STATUS_B_U1, spans (INCIDENT_STATUS_ID, ZD_EDITION_NAME), which supports the edition-based redefinition feature in Release 12.2. The documented business-key candidate INCIDENT_SUBTYPE appears on the CS_INCIDENT_STATUSES_B_UK unique key.

• INCIDENT_STATUS_ID – Surrogate primary key identifying the status.
• INCIDENT_SUBTYPE – Subtype/category qualifier that distinguishes status variants.
• NAME – Non-translated status name token.
• STATUS_CODE and STATUS_CLASS_CODE – Internal codes categorizing the status.
• CLOSE_FLAG, RESOLVED_FLAG, ON_HOLD_FLAG, PENDING_APPROVAL_FLAG, RESPONDED_FLAG – Lifecycle indicator flags.
• DISALLOW_REQUEST_UPDATE, DISALLOW_NEW_ACTION, DISALLOW_ACTION_UPDATE, DISALLOW_NEW_CHARGE, DISALLOW_RMA, DISALLOW_AGENT_DISPATCH – Action and edit restrictions enforced at the status.
• SEEDED_FLAG and UPGRADED_STATUS_FLAG – Indicate Oracle-seeded versus customer-defined or upgraded statuses.
• START_DATE_ACTIVE and END_DATE_ACTIVE – Effective dating for the status.
• SORT_ORDER, DISPLAY_COLOR, and RGB_COLOR – Presentation attributes for status lists and indicators.
• INTERMEDIATE_STATUS_ID, REJECTION_ACTION_STATUS_ID, APPROVAL_ACTION_STATUS_ID – References to related workflow statuses.
• SECURITY_GROUP_ID – Foreign key to FND_SECURITY_GROUPS, scoping the record to a security group.
• OBJECT_VERSION_NUMBER – Optimistic locking column.
• ZD_EDITION_NAME – Edition identifier used in 12.2 edition-based redefinition.

Common Use Cases and Queries

The most frequent use is resolving an incident's current status to its behavioral flags, and reporting status distribution across a queue. A typical join returns the status definition for each Service Request:

SELECT s.incident_status_id, s.name, s.status_code, s.close_flag, s.on_hold_flag
FROM cs.cs_incident_statuses_b s
WHERE s.incident_status_id = :status_id;

Reporting by status class or lifecycle state is common:

SELECT s.status_class_code, COUNT(*)
FROM cs.cs_incidents_all_b i, cs.cs_incident_statuses_b s
WHERE i.incident_status_id = s.incident_status_id
GROUP BY s.status_class_code;

Determining which actions are permitted at a status is another frequent need, using the DISALLOW_* flags. Administrators also query SEEDED_FLAG to distinguish Oracle-provided statuses from custom ones, and use START_DATE_ACTIVE/END_DATE_ACTIVE to identify currently effective statuses. Because status definitions drive transitions, the table is also consulted when validating allowed status changes configured in CS_SR_STATUS_TRANSITIONS.

Related Objects

CS_INCIDENT_STATUSES_B is referenced by numerous Service tables through INCIDENT_STATUS_ID. The most significant dependencies are:

• CS_INCIDENTS_ALL_B.INCIDENT_STATUS_ID – The Service Requests themselves; primary consumer of status definitions.
• CS_INCIDENT_STATUSES_TL.INCIDENT_STATUS_ID – Translated names and descriptions.
• CS_INCIDENT_CYCLE_STEPS.INCIDENT_STATUS_ID – Statuses used within group/cycle processing.
• CS_SR_ALLOWED_STATUSES.INCIDENT_STATUS_ID – Controls which statuses are permitted in a given context.
• CS_SR_STATUS_TRANSITIONS.FROM_INCIDENT_STATUS_ID and TO_INCIDENT_STATUS_ID – Defines valid status-to-status transitions.
• CS_SR_STATUS_GROUPS_B.DEFAULT_INCIDENT_STATUS_ID – Default status per status group.
• CS_SR_ACTION_DETAILS.INCIDENT_STATUS_ID and CS_SR_ACTION_TRIGGERS.INCIDENT_STATUS_ID – Link statuses to actions and triggers.
• CS_INCIDENTS_AUDIT_B.INCIDENT_STATUS_ID – Historical status tracking on incidents.
• BIV_BAC_SUM_MV.INCIDENT_STATUS_ID – Materialized view used in Service reporting/analytics.
• FND_SECURITY_GROUPS – Referenced via SECURITY_GROUP_ID for data security scoping.