Search Results okc_assents_v




Overview
Explore in AI Chat

Overview

OKC_ASSENTS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, belonging to the OKC – Contracts Core product family. The view exposes data from the OKC_ASSENTS base table, presenting one row for each assertion or contractual term record stored by the Contracts Core module. Its primary role is to provide a stable, query-friendly interface for concurrent programs, Oracle Reports, and custom extensions that must read assertion data without directly referencing the transactional base table.

The view is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2 and is classified as a "View for table OKC_ASSENTS." In practice it acts as a thin projection layer: the view text performs a straight SELECT ... FROM OKC_ASSENTS ASTB with no joins, filters, or calculations. Because the projection is one-to-one, the view preserves the cardinality, row order semantics, and DML behaviour of the underlying table, while retaining the same column names in most cases.

The user search term "allowed_yn" maps directly to the ALLOWED_YN column exposed by this view. That column is a Yes/No indicator that controls whether a given assertion is permitted in the context of its parent contract line or terms template. Querying OKC_ASSENTS_V is therefore the standard method for retrieving the allowed/not-allowed state of an assertion alongside its status and operation codes.

Underlying Base Objects

The documented view text references a single base object:

  • OKC_ASSENTS — the Contracts Core assertion table, accessed in the view through the synonym OKC_ASSENTS ASTB.

No other tables, lookup views, or external objects appear in the documented definition. The relationship is therefore strictly one-to-many in the sense that the view inherits every row and column of OKC_ASSENTS without aggregation or de-duplication. The ROW_ID column is derived from ASTB.ROWID, providing a physical row identifier that can be used in forms or for direct row-level correlation back to the base table. All remaining columns are copied verbatim from the base table, which means referential behaviour, locking semantics, and the presence of attribute columns are identical to the underlying object.

Key Columns

  • ROW_ID — the Oracle ROWID of the underlying OKC_ASSENTS row, useful for direct table addressing.
  • ID — primary identifier of the assertion record.
  • STS_CODE — status code indicating the lifecycle state of the assertion.
  • OPN_CODE — operation code describing the action associated with the assertion.
  • STE_CODE — the contract terms or template entity code.
  • SCS_CODE — the source or system code for the assertion.
  • ALLOWED_YN — a Yes/No flag indicating whether the assertion is permitted; this is the column most commonly searched for by name.
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the Oracle Forms layer.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the standard DFF (descriptive flexfield) columns exposed for extensibility.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.

Common Use Cases and Queries

Typical usage includes validating whether an assertion is allowed before processing a contract, reporting on assertion statuses, and feeding integrations that require assertion data. A common query filters on ALLOWED_YN to isolate permitted assertions:

SELECT id, sts_code, opn_code, allowed_yn
FROM   okc_assents_v
WHERE  allowed_yn = 'Y'
AND    sts_code  = :p_status_code;

Because the view includes the ROW_ID, it can also be used to locate the physical row for bulk updates or troubleshooting:

SELECT row_id, id, last_update_date
FROM   okc_assents_v
WHERE  id = :p_assertion_id;

For integration and audit reporting, the WHO columns and ATTRIBUTE1–15 provide enough context to reconcile changes. As with any APPS-owned Contracts Core object, queries should be schema-qualified as APPS.OKC_ASSENTS_V when executed from a non-APPS session, and DML should be performed against the base table rather than the view.