Search Results okc_rep_con_actions_u1




Overview

OKC.OKC_REP_CON_ACTIONS is a seed data table in the Oracle Contracts (OKC) schema that drives the behavior of the Contracts Repository user interface. It defines, for each combination of a contract page mode and a contract status, which actions are permitted or suppressed within the Oracle E-Business Suite Contracts Repository responsibility. The table is stored in the APPS_TS_SEED tablespace, consistent with its role as a repository of setup and control values rather than transaction data.

The object is owned by the OKC schema, carries FND Design Data registration as OKC.OKC_REP_CON_ACTIONS, and is marked VALID in the ETRM 12.2.2 documentation set. The metadata notes that the object is subject to the standard Oracle restriction on direct application data access except through supported Oracle Applications programs. Heuristically, the mined relationship structure classifies OKC_REP_CON_ACTIONS as a standalone data object with no foreign key references to other tables. Under a Data Vault modeling interpretation, this would suggest treating it as a small reference or hub-style configuration table rather than a link or satellite, since no dependent relationships are documented.

Key Information Stored

The table has eleven documented columns. The composite primary key is OKC_REP_CON_ACTIONS_PK, defined on PAGE_MODE, STATUS_CODE, and ACTION_CODE. These three columns also participate in the unique index OKC_REP_CON_ACTIONS_U1, which adds ZD_EDITION_NAME to the key list, making U1 the business-key candidate that includes the edition discriminator.

  • PAGE_MODE (VARCHAR2, 30) — The UI context in which an action applies. Valid values are VIEW and UPDATE.
  • STATUS_CODE (VARCHAR2, 30) — The contract status for which the action rule applies. Values are drawn from FND_LOOKUPS where LOOKUP_TYPE equals OKC_REP_CONTRACT_STATUSES.
  • ACTION_CODE (VARCHAR2, 30) — The action being controlled. Values come from FND_LOOKUPS where LOOKUP_TYPE equals OKC_REP_CON_ACTIONS.
  • DISABLED_FLAG (VARCHAR2) — Indicates whether the status/action relationship is disabled. Values are Y or N.
  • OBJECT_VERSION_NUMBER (NUMBER) — Optimistic locking counter, set to 1 on insert and incremented on update, used by APIs to verify the current record.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who columns recording audit and session context.
  • ZD_EDITION_NAME (VARCHAR2, 30) — Edition discriminator used by the editioning framework and included in the U1 unique index.

Common Use Cases and Queries

The primary use case is determining action availability in the Contracts Repository. Administrators and developers query this table to confirm why a given action (for example, an approval, cancel, or amend operation) does or does not appear for a contract status. A typical query resolving enabled actions for a status in UPDATE mode is:

SELECT ACTION_CODE FROM OKC.OKC_REP_CON_ACTIONS WHERE STATUS_CODE = :status AND PAGE_MODE = 'UPDATE' AND DISABLED_FLAG = 'N';

Joining to FND_LOOKUPS resolves descriptive meanings for both STATUS_CODE and ACTION_CODE, supporting configuration audits. Note that OKC_REP_CON_ACTIONS does not reference any database object, so it cannot be traversed upward by foreign key; reverse dependencies list OKC_REP_CON_ACTIONS# as the editioning view. Reporting should therefore join through the lookup values rather than expected FK paths.

Related Objects

  • OKC_REP_CON_ACTIONS_U1 — Unique index on PAGE_MODE, ACTION_CODE, STATUS_CODE, ZD_EDITION_NAME; the documented business-key candidate.
  • OKC_REP_CON_ACTIONS_PK — Primary key on PAGE_MODE, STATUS_CODE, ACTION_CODE.
  • OKC_REP_CON_ACTIONS# — Editioning view over the base table; listed as the sole documented dependent object.
  • FND_LOOKUPS — Source of valid STATUS_CODE values via OKC_REP_CONTRACT_STATUSES and ACTION_CODE values via OKC_REP_CON_ACTIONS.

No other tables, views, or APIs are documented as referencing or being referenced by this object, reinforcing its standalone classification and its role as a self-contained seed configuration entity.