Results for “okc_subclass_roles_v”

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

Overview

OKC_SUBCLASS_ROLES_V is an Oracle E-Business Suite view owned by the APPS schema and classified under the OKC – Contracts Core product. Its status is VALID across EBS 12.1.1 and 12.2.2. The view is a thin projection over the OKC_SUBCLASS_ROLES table, exposing every stored attribute of the underlying entity without joins, aggregation, or filtering. It therefore serves as a read-only reporting and integration interface for subclass-to-role assignments within the Contracts Core data model.

In the OKC architecture, a contract subclass (SCS_CODE) represents a user-defined or seeded contract classification, while a role (RLE_CODE) identifies the party function associated with that subclass—for example, party roles such as customer, supplier, or internal owner. The intersection of these two dimensions is maintained in OKC_SUBCLASS_ROLES, and OKC_SUBCLASS_ROLES_V is the canonical API-facing representation of that intersection. Because the view carries ROW_ID derived from the base table ROWID, it remains updatable in the Oracle sense for simple DML through the view, although the primary consumption pattern is read-only querying.

Underlying Base Objects

The documented base object is OKC_SUBCLASS_ROLES, referenced in the APPS schema through a synonym. The view definition selects from OKC_SUBCLASS_ROLES SREB using a straight column-by-column mapping with no WHERE clause. Consequently:

• Row cardinality between the view and the base table is identical; the view introduces no filtering.
• No joins to OKC_SUBCLASSES, OKC_ROLES, or any lookup table are performed inside the view. Descriptions for RLE_CODE and SCS_CODE must be resolved separately by the consumer.
• The view is a natural candidate for the ROWID alias ROW_ID, which supports identification of a row even in the absence of a stable primary key exposed to the report layer.

Key Columns

• ROW_ID – ROWID of the underlying base-table row; useful for duplicate detection and direct row addressing.
• ID – Surrogate primary key of the subclass-role assignment record.
• OBJECT_VERSION_NUMBER – Optimistic locking token maintained by the framework; increments on each update.
• RLE_CODE – The role code, the column that most queries against this view filter on. It is the value returned when users search for "rle_code".
• SCS_CODE – The contract subclass code to which the role is attached.
• ACCESS_LEVEL – Controls the visibility or permission level applied to the role within the subclass.
• START_DATE / END_DATE – Effective dating window for the assignment, enabling date-effective reporting.
• 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 determining which roles are valid for a given subclass before creating a contract, auditing role assignments for a specific role code, and feeding date-effective extracts into downstream reporting. A sample query retrieving all active assignments for a role is shown below.

SELECT scs_code, rle_code, access_level, start_date, end_date
FROM okc_subclass_roles_v
WHERE rle_code = :p_rle_code
AND SYSDATE BETWEEN NVL(start_date, SYSDATE) AND NVL(end_date, SYSDATE + 1);

A second common pattern returns all roles attached to one subclass:

SELECT rle_code, access_level
FROM okc_subclass_roles_v
WHERE scs_code = :p_scs_code;

Because the view exposes no descriptive columns, production reports generally join it to OKC_ROLES_V or OKC_SUBCLASSES_V to resolve names, and to FND lookups where the role code is validated. All queries should be executed against the APPS schema or a synonym-owning reporting schema with appropriate grants.