Results for “default_yn”

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

Overview

OKC_STATUSES_B is a Contracts Core (OKC) foundation table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores the user-defined status values which describe the lifecycle state of a contract. Every contract header, contract line, contract history record, and contract-related assertion resolves its status through a code drawn from this table. Because status drives approval routing, amendment eligibility, termination logic, and reporting, OKC_STATUSES_B functions as a controlled lookup or reference list rather than a transactional table. It is seeded and subsequently extended by implementers to reflect an enterprise's contract lifecycle vocabulary (for example, Draft, Submitted for Approval, Active, Expired, Cancelled, Terminated).

From a Data Vault modeling perspective, the mined relationship structure suggests this table behaves as a hub-leaning reference entity. Its stable, non-volatile identity — the status CODE — acts as the business key, while descriptive attributes such as the seeded system status, default flag, and effective dates are candidates for satellite treatment if the subject area were modeled formally. This classification is a modeling suggestion only; in the delivered EBS schema the table is a conventional reference table.

Key Information Stored

The documented physical schema contains 13 columns. The most significant are:

• CODE — The primary key column (OKC_STATUSES_B_PK). It holds the short internal identifier for a status, and is the value stored by every foreign key that references this table.
• STE_CODE — The seeded system status code to which the user-defined status maps. This links a custom status back to the delivered EBS status semantics used internally by contracts processing.
• DEFAULT_YN — Flag indicating whether the status is the default applied when a new contract or line is created.
• START_DATE and END_DATE — Effective dating that controls when the status value is valid and selectable.
• SECURITY_GROUP_ID — References FND_SECURITY_GROUPS, supporting multi-organization and security-group partitioning of reference data.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the Oracle Applications Framework to prevent concurrent update conflicts.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS WHO-column audit trail capturing row creation and last modification.
• ZD_EDITION_NAME — The editioning column supporting online patching in 12.2.x; combined with CODE it forms unique index OKC_STATUSES_U1, the business-key candidate.

The distinction between the surrogate-style primary key (CODE) and the business-key candidate (CODE, ZD_EDITION_NAME) is important: the composite unique index exists to satisfy Edition-Based Redefinition requirements in 12.2.2, where the same logical code may exist under different edition names during an online patch cycle. Queries that must return a single row across editions should therefore filter or join carefully on ZD_EDITION_NAME.

Common Use Cases and Queries

Typical scenarios include validating status values before contract updates, populating status list-of-values in custom concurrent programs, and generating lifecycle reports that count contracts by status. A representative query joining the header table to its status reference:

• SELECT h.contract_number, s.code, s.start_date FROM okc_k_headers_b h, okc_statuses_b s WHERE h.sts_code = s.code;
• Enumerating selectable statuses: SELECT code FROM okc_statuses_b WHERE default_yn = 'Y' AND SYSDATE BETWEEN start_date AND NVL(end_date, SYSDATE);
• Auditing status transitions through history: SELECT sts_code_from, sts_code_to FROM okc_k_history_b;

Because status values are user defined, reporting logic should never hard-code status literals. Instead, resolve them through this table or through the seeded STE_CODE mapping so that customizations remain portable across environments.

Related Objects

The FK metadata identifies five dependent objects plus one parent reference:

• OKC_K_HEADERS_B — Contract headers; STS_CODE references OKC_STATUSES_B.CODE. This is the primary consumer of status values.
• OKC_K_LINES_B — Contract lines; STS_CODE references the status table, enabling line-level lifecycle tracking.
• OKC_K_HISTORY_B — Contract status history; both STS_CODE_FROM and STS_CODE_TO reference OKC_STATUSES_B.CODE, forming a from/to status transition model.
• OKC_ASSENTS — Contract assertions; STS_CODE references the status table.
• FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID, providing the security partitioning parent.

These relationships confirm OKC_STATUSES_B as a low-volume, high-fan-in reference hub underlying the Contracts Core transactional model.