Results for “okc_subclass_resps”

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

Overview

OKC_SUBCLASS_RESPS is a Contracts Core (OKC) table in Oracle E-Business Suite 12.1.1 and 12.2.2 that defines the access level granted to a subclass of contract for a specific AOL responsibility. In practice, it functions as the security authorization bridge between contract classification and the Oracle Applications responsibility model: each row grants a named responsibility a defined level of access to contracts belonging to a particular subclass. Without a matching row, a responsibility has no subclass-level authorization, making this table central to row-level security on the Contracts workbench and related contract inquiry and authoring pages.

From a Data Vault modeling perspective, the mined heuristic classifies this object as satellite-leaning. Operationally it behaves as an intersection or link table because the primary key is a composite of two business identifiers (SCS_CODE and RESP_ID); the satellite characteristic arises from the descriptive ACCESS_LEVEL attribute and the standard EBS audit and date-effective columns carried on the row. Modelers should treat the classification as a suggestion rather than a strict architectural directive.

Key Information Stored

The table contains 11 documented columns. The most significant are:

• SCS_CODE — the contract subclass code; part of the composite primary key and foreign key to OKC_SUBCLASSES_B. Identifies which subclass of contract the authorization applies to.
• RESP_ID — the AOL responsibility identifier; the second component of the composite primary key. Identifies the responsibility receiving the grant.
• ACCESS_LEVEL — the descriptive attribute stating the level of access granted (for example, full, view-only, or update). This is the core business payload of the row.
• START_DATE and END_DATE — date-effective range controlling when the authorization is active.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, supporting multi-org or security-group partitioned access in global deployments.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS WHO columns capturing audit and concurrency information.

The surrogate primary key is OKC_SUBCLASS_RESPS_PK, defined on (SCS_CODE, RESP_ID). A unique index, OKC_SUBCLASS_RESPS_U1, also covers (SCS_CODE, RESP_ID), confirming that the pairing of subclass and responsibility is the business-key candidate and that duplicate grants for the same subclass-responsibility combination are not permitted.

Common Use Cases and Queries

Typical scenarios include auditing which responsibilities can see a given contract subclass, provisioning security for a new responsibility, and diagnosing "no access" errors on the Contracts workbench. A representative query joins the table to its parent subclass definition:

• List all responsibilities authorized for a subclass:
  SELECT s.scs_code, r.resp_id, r.access_level FROM okc_subclass_resps r, okc_subclasses_b s WHERE r.scs_code = s.scs_code AND r.scs_code = :scs_code;
• Find effective grants as of the current date by filtering on START_DATE and END_DATE.
• Reverse lookup: enumerate the subclasses a responsibility may access, restricted by SECURITY_GROUP_ID where applicable, to reconcile against FND_SECURITY_GROUPS.

Reporting use cases focus on segregation-of-duties audits and access-certification reviews, where the ACCESS_LEVEL value is compared against the responsibility's menu and function grants in FND.

Related Objects

The following objects are most significant in relation to OKC_SUBCLASS_RESPS, with the documented join columns:

• OKC_SUBCLASSES_B — parent table joined on SCS_CODE; holds the subclass definition the grant applies to.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID; partitions access in multi-security-group installations.
• FND_RESPONSIBILITY — resolves RESP_ID to the application responsibility name and application short name for reporting.
• OKC_SUBCLASSES_TL — provides translated subclass names for user-facing reports.
• OKC_CONTRACTS_ALL / OKC_K_HEADERS_ALL — the contract header tables whose rows are filtered at runtime by the subclass-responsibility authorization defined here.

Consult the OKC Contracts Core API layer for supported maintenance rather than direct DML, as authorization data is validated against subclass and responsibility definitions.