Results for “status_code”

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

Overview

OKX_INCIDENT_STATUSES_V is a lightweight reporting and integration view owned by the APPS schema in Oracle E-Business Suite. It belongs to the OKX – Contracts Integration product family, which serves as the bridge between Oracle Contracts and Oracle Service (Service Requests/Incidents). The view is documented in ETRM for both release 12.1.1 and 12.2.2 with a status of VALID, and its stated purpose is to expose "service request and action statuses" in a simplified, consumer-friendly form.

Rather than publishing the full set of columns available on the underlying incidents table, OKX_INCIDENT_STATUSES_V projects only two columns: a contract service identifier and a decoded status code. This minimal footprint makes the view suitable for downstream lookups, cross-product joins, and interfaces that need to determine whether a given contract service line is open or closed without carrying the weight of the entire service request record. In practice it functions as a denormalized status access layer over Service (CS) data.

Underlying Base Objects

Per the documented ETRM metadata, the view references a single base object: CS_INCIDENTS_ALL_B, accessed by the APPS schema through a synonym. CS_INCIDENTS_ALL_B is the base ("_B") table of the Oracle Service incidents/service requests entity, storing the core, non-translated attributes of each service request.

The relationship is one-to-one at the row level: the view selects directly from the base table with no joins, aggregations, or groupings. Consequently, OKX_INCIDENT_STATUSES_V inherits the base table's cardinality and returns one row per incident record present in CS_INCIDENTS_ALL_B, restricted only by whatever predicate the caller applies. The view does not consult any translation ("_TL") table, consistent with the fact that it exposes only a code and an identifier rather than descriptive text.

Key Columns

• CONTRACT_SERVICE_ID — The identifier linking a service request/incident back to its associated contract service line. This is the column users most frequently search on (the search term "contract_service_id" maps directly to it), and it is the natural join key between OKX integration objects and Contracts data.
• STATUS_CODE — A derived value produced by a DECODE expression over the base table's STATUS_FLAG column: when STATUS_FLAG equals 'O', the view returns 'OPEN'. No other mapping is defined in the documented view text, so this column yields 'OPEN' for open incidents and NULL otherwise.

Because the projection is so narrow, the view intentionally omits dates, owners, severity, and other incident attributes. Any consumer requiring richer service request detail must query CS_INCIDENTS_ALL_B directly or join additional CS views.

Common Use Cases and Queries

The view is typically used to drive conditional logic in OKX integration flows—for example, to check whether a contract's service request remains open before permitting a further action—and in simple operational reports.

• Retrieve the status for a specific contract service line.
• List all open service requests associated with contract services.
• Join to contract service tables to enrich reporting.

Sample SQL:

• SELECT contract_service_id, status_code FROM apps.okx_incident_statuses_v WHERE contract_service_id = :p_contract_service_id;
• SELECT contract_service_id FROM apps.okx_incident_statuses_v WHERE status_code = 'OPEN';
• SELECT s.contract_service_id, s.status_code FROM apps.okx_incident_statuses_v s, apps.okc_k_lines_v l WHERE s.contract_service_id = l.id; (illustrative join to a contract line source).