Search Results current_status_code

Overview

The OKC_DEL_STATUS_COMBXNS table in the Oracle E-Business Suite Contracts Core (OKC) module defines the allowable transitions between statuses within the contract lifecycle. Its name reflects its function as a status combinations table, and its documented description states that it "contains valid combinations of statuses." Each row represents a permitted transition from a current status to an allowable status for the user or process identified by STATUS_CHANGED_BY. In both Oracle EBS 12.1.1 and 12.2.2, this table acts as configuration and validation data that governs the behavior of the contract status change workflow, rather than transactional contract data itself.

From a Data Vault modeling perspective, the mined classification for this object is standalone. This is a heuristic suggestion rather than a physical design directive. Because the table primarily contains reference and validation data describing permitted status pairings, such data would typically be modeled as a reference or lookup construction rather than a hub, link, or satellite. There are no documented foreign keys in the metadata, which reinforces its treatment as an independent reference source.

Key Information Stored

The table is documented with nine columns in the ETRM 12.2.2 physical schema. The most significant columns are the following:

• CURRENT_STATUS_CODE — the status from which a change is being initiated.
• ALLOWABLE_STATUS_CODE — the status to which the contract may transition.
• STATUS_CHANGED_BY — the identifier of the user, role, or process permitted to perform the transition.
• CREATED_BY, CREATION_DATE — standard audit columns recording who created the row and when.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns recording the most recent modification.
• ZD_EDITION_NAME — the editioning column used to segregate rows by edition.

The documented primary key is OKC_DEL_STATUS_COMBXNS_PK, defined on the combination of STATUS_CHANGED_BY, CURRENT_STATUS_CODE, and ALLOWABLE_STATUS_CODE. This composite key confirms that the natural business identity of a row is the triple of changer, source status, and target status. A unique index, OKC_DEL_STATUS_COMBXNS_U1, is documented on the same three columns plus ZD_EDITION_NAME. Because it includes the editioning column, U1 serves as the business-key candidate within a given edition and enforces uniqueness across editions. The ZD_EDITION_NAME column therefore plays a role in the uniqueness semantics of the table and must be considered when querying in an editioned environment.

Common Use Cases and Queries

Typical use cases focus on validating and reporting permitted contract status transitions. A common query retrieves all allowable target statuses for a given source status:

• SELECT allowable_status_code FROM okc_del_status_combxns WHERE current_status_code = :current_status;
• SELECT current_status_code, allowable_status_code, status_changed_by FROM okc_del_status_combxns WHERE status_changed_by = :user_id;
• SELECT current_status_code, COUNT(*) FROM okc_del_status_combxns GROUP BY current_status_code;

In an editioned environment, queries should filter or explicitly account for ZD_EDITION_NAME. Operational scenarios include troubleshooting blocked status changes, auditing which users or roles are configured to advance contracts, and generating reporting on the configured state machine.

Related Objects

The mined relationship data classifies this object as standalone, meaning no foreign keys are documented to other tables. The principal reference within the metadata is the primary key constraint OKC_DEL_STATUS_COMBXNS_PK, whose columns (STATUS_CHANGED_BY, CURRENT_STATUS_CODE, ALLOWABLE_STATUS_CODE) join this table to related status configuration. In practice, the status codes stored here are consumed by contract status APIs and validation logic in the OKC module, such as OKC_CONTRACT_STATUS and the OKC Contracts status change APIs, which resolve the current and allowable status codes. Because no FK metadata is provided, integrators should treat the relationships to these status APIs and validation routines as logical dependencies rather than enforced constraints, and confirm them against the actual schema in their 12.1.1 or 12.2.2 instance.