Results for “okc_assents”

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

Overview

The OKC_ASSENTS table is a core configuration object within the Oracle EBS Contracts Core (OKC) module. Its documented description states that it "indicates if an Operation is to be performed for a Subclass of Contract while in a Status." In practical terms, this table functions as an authorization or permission matrix that governs which contract lifecycle operations are permitted for a given subclass/status combination. Each row answers the question: for this subclass of contract, in this status, is this operation allowed?

The object resides in the OKC schema and is marked VALID in the ETRM 12.2.2 physical schema documentation, containing 30 documented columns. From a Data Vault modeling perspective, the mined FK structure suggests classifying OKC_ASSENTS as a link table. This heuristic classification reflects the table's role as an associative entity that resolves the many-to-many relationship between contract subclasses, contract statuses, included operations, and their associated stepper definitions. It should be treated as a modeling suggestion rather than a prescriptive implementation directive.

Key Information Stored

OKC_ASSENTS is composed of a small set of meaningful business columns supported by a broad set of standard EBS audit and descriptive-flex columns. The most significant columns are:

• ID – The surrogate primary key, enforced by the OKC_ASSENTS_PK constraint. This is a system-generated identifier and carries no business meaning.
• SCS_CODE – References a contract subclass in OKC_SUBCLASSES_B, identifying which subclass the rule applies to.
• STS_CODE – References a contract status in OKC_STATUSES_B, identifying the lifecycle state in which the operation is evaluated.
• OPN_CODE – Identifies the operation being authorized.
• STE_CODE – References OKC_INCLUDED_OPERATIONS, linking the assertion to a specific included operation definition.
• ALLOWED_YN – The core flag indicating whether the specified operation is permitted for the subclass/status combination. This is the value most business rules ultimately consult.
• OBJECT_VERSION_NUMBER – Supports optimistic locking for concurrent updates.
• SECURITY_GROUP_ID – References FND_SECURITY_GROUPS and enforces multi-org/security-group data segregation.
• ZD_EDITION_NAME – The editioning column introduced for EBR (Edition-Based Redefinition) compatibility in 12.2.x.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard "Who" audit columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 – The standard DFF (Descriptive Flexfield) context and attribute columns, available for customer-specific extensibility.

Two unique indexes serve as documented business-key candidates: OKC_ASSENTS_U1 (ID, ZD_EDITION_NAME) and OKC_ASSENTS_U2 (SCS_CODE, STS_CODE, OPN_CODE, STE_CODE, ZD_EDITION_NAME). U2 confirms that the natural business key is the combination of subclass, status, operation, and stepper, with the edition name required for EBR.

Common Use Cases and Queries

This table is most commonly consulted when diagnosing why a contract operation (approve, terminate, renew, etc.) is available or hidden in the Contract Management UI. A typical diagnostic query joins the subclass and status codes:

• Determine whether an operation is allowed: SELECT ALLOWED_YN FROM OKC_ASSENTS WHERE SCS_CODE = :scs AND STS_CODE = :sts AND OPN_CODE = :opn;
• List all operations allowed for a subclass in a status: join OPN_CODE to lookup tables to obtain operation labels.
• Audit configuration drift: compare ALLOWED_YN values across development, test, and production environments for the same SCS_CODE/STS_CODE/OPN_CODE combination.
• Report on enabled lifecycle operations per contract subclass for administrative review or security assessment.

Related Objects

The following objects are the most significant dependencies, based on the documented foreign-key relationships:

• OKC_SUBCLASSES_B – Referenced via OKC_ASSENTS.SCS_CODE; supplies the subclass definition.
• OKC_STATUSES_B – Referenced via OKC_ASSENTS.STS_CODE; supplies the status definition.
• OKC_INCLUDED_OPERATIONS – Referenced via OKC_ASSENTS.STE_CODE; supplies the included operation/stepper definition.
• FND_SECURITY_GROUPS – Referenced via OKC_ASSENTS.SECURITY_GROUP_ID; enforces data security grouping.
• OKC_ASSENTS_PK, OKC_ASSENTS_U1, and OKC_ASSENTS_U2 – The primary key and unique-index constraints that enforce integrity on this table.

Because the table is a link entity, updates to OKC_ASSENTS rows propagate directly into runtime operation availability, making it a high-impact configuration table for Contract Management behavior.