Search Results okc_subclass_resps




Overview
Explore in AI Chat

Overview

The table OKC_SUBCLASS_RESPS is a core security and authorization object within the Oracle E-Business Suite Contracts Core module (OKC). It functions as a mapping table that defines the level of access granted to a specific Application Object Library (AOL) responsibility for a given contract subclass. This mechanism is fundamental to implementing data security and functional access control within the Contracts application, ensuring that users operating under a particular responsibility can only view or modify contract data for the subclasses explicitly permitted to them. By linking responsibilities to contract subclasses, it enables precise, role-based governance over contract types and their associated business processes.

Key Information Stored

The table stores a composite record for each unique responsibility and contract subclass pairing where access is granted. Its structure is defined by a primary key composed of two columns: SCS_CODE and RESP_ID. The SCS_CODE column stores the internal code identifying a specific contract subclass, as defined in the OKC_SUBCLASSES_B table. The RESP_ID column stores the unique identifier for an AOL responsibility (from the FND_RESPONSIBILITY table). While the provided metadata does not list additional columns, such a table typically includes an ACCESS_LEVEL or similar column to specify the type of access (e.g., VIEW, MODIFY, FULL). The existence of a record in this table generally implies that the specified responsibility has been granted some form of access to the specified subclass.

Common Use Cases and Queries

A primary use case is auditing security setup to verify which responsibilities can access critical contract subclasses. System administrators frequently query this table to troubleshoot user access issues or to replicate security models during implementation. A common reporting query involves joining to FND_RESPONSIBILITY_TL for the responsibility name and OKC_SUBCLASSES_TL for the subclass name to produce a human-readable access matrix.

  • Sample Query: To list all responsibilities with access to a specific subclass code ('SERVICE'), one might use: SELECT r.responsibility_name, s.scs_code FROM okc_subclass_resps sr, fnd_responsibility_vl r, okc_subclasses_b s WHERE sr.resp_id = r.responsibility_id AND sr.scs_code = s.scs_code AND s.scs_code = 'SERVICE';
  • Administrative Action: Granting a new responsibility access to a set of subclasses involves inserting records into this table for each permitted SCS_CODE and the corresponding RESP_ID.

Related Objects

OKC_SUBCLASS_RESPS is centrally linked to two key master tables via foreign key constraints, ensuring referential integrity.

  • OKC_SUBCLASSES_B: This is the primary foreign key relationship. The column OKC_SUBCLASS_RESPS.SCS_CODE references OKC_SUBCLASSES_B.SCS_CODE. This ensures that every access rule is defined for a valid, existing contract subclass.
  • FND_RESPONSIBILITY: Although not explicitly listed in the provided foreign key metadata, the RESP_ID column logically references FND_RESPONSIBILITY.RESPONSIBILITY_ID. This link ties the access rule to a valid EBS responsibility.
  • OKC_SUBCLASS_RESPS_PK: The primary key constraint (SCS_CODE, RESP_ID) enforces uniqueness, preventing duplicate access grants for the same responsibility and subclass combination.