Search Results okc_role_sources_u1

Overview

The OKC.OKC_ROLE_SOURCES table is a reference and configuration table within the Oracle E-Business Suite Contracts (OKC) schema. It defines the valid data sources from which a party can be drawn when that party plays a specific role in a contract. Because contract semantics differ across business flows, the permitted source of a party often depends on whether the contract is a buy contract or a sell contract. The table therefore acts as a mapping between role codes, the buy/sell direction, and the underlying entity view from which party records are resolved.

The canonical example documented for this object is the relationship between the roles Customer and Vendor. In a sell contract, the Customer is typically sourced from HZ_PARTYS, and the Vendor can also come from HZ_PARTYS provided internal organizations have been defined as parties. In a buy contract, the Customer again comes from HZ_PARTYS under the same condition, but the Vendor is instead sourced from PO_VENDORS. This differentiation is the core purpose of OKC_ROLE_SOURCES and explains why BUY_OR_SELL is part of the table's unique key.

The ETRM metadata classifies this object as satellite-leaning under a heuristic Data Vault model. This suggests it is best treated as a descriptive satellite that hangs off the role/direction business key, carrying attributes such as the object code, access level, and audit columns. It is not a transaction hub and does not represent an event or a many-to-many association on its own.

Key Information Stored

The table records one active row per valid role/direction/start-date combination. The most important columns are:

• RLE_CODE — the role code, for example CUSTOMER, associated with the permitted sources. This is a business-key column.
• BUY_OR_SELL — denotes whether the role definition applies to a buy or a sell contract. This is also a business-key column.
• START_DATE — the beginning of the active period, defined as one second after midnight on the indicated date. This completes the business key.
• END_DATE — the end of the active period, one second before midnight on the indicated date. Used for effective-dating the configuration row.
• JTOT_OBJECT_CODE — a foreign key to JTF_OBJECTS_B that identifies the view referenced by the associated OBJECT_ID columns, thereby specifying the actual data source for the party.
• OBJECT_VERSION_NUMBER — a sequential number set to 1 on insert and incremented on update, used by APIs to enforce optimistic concurrency.
• ACCESS_LEVEL — indicates the protection level for the record.
• SECURITY_GROUP_ID — used in hosted environments to segregate data.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Who columns for auditing.
• ZD_EDITION_NAME — the editioning column present in the 12.2.2 physical schema.

From a key-modelling perspective, the primary key is OKC_ROLE_SOURCES_PK on (RLE_CODE, BUY_OR_SELL, START_DATE). The unique index OKC_ROLE_SOURCES_U1 — the object the user searched for — enforces the same business key and, in the documented 12.2.2 schema, is extended by ZD_EDITION_NAME: (RLE_CODE, BUY_OR_SELL, START_DATE, ZD_EDITION_NAME). There is no separate surrogate identity column; the business key itself serves as the primary key.

Common Use Cases and Queries

Typical reporting and integration scenarios involve resolving which entity table provides a party for a given role and contract direction, and validating that a configured role source is still active on a given date.

• Resolve the source for a role: join OKC_ROLE_SOURCES to JTF_OBJECTS_B on JTOT_OBJECT_CODE to determine the backing view for a role, filtered by RLE_CODE and BUY_OR_SELL.
• Effective-dated lookups: constrain SYSDATE between START_DATE and END_DATE to return only the source row active at the current point in time.
• Audit and migration checks: query by OBJECT_VERSION_NUMBER or the Who columns to detect recently modified or stale configuration rows.

A representative query pattern is:

SELECT r.RLE_CODE, r.BUY_OR_SELL, j.OBJECT_CODE
FROM OKC.OKC_ROLE_SOURCES r, JTF.JTF_OBJECTS_B j
WHERE r.JTOT_OBJECT_CODE = j.OBJECT_CODE
AND r.RLE_CODE = :p_role_code
AND r.BUY_OR_SELL = :p_buy_or_sell
AND SYSDATE BETWEEN r.START_DATE AND NVL(r.END_DATE, SYSDATE + 1);

This pattern is commonly used by contract creation and party-defaulting logic, and by diagnostics that explain why a particular party source was selected for a contract role.

Related Objects

The following objects are most significant in relation to OKC_ROLE_SOURCES:

• JTF_OBJECTS_B — referenced by JTOT_OBJECT_CODE; supplies the object/view definition that identifies the actual data source.
• FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID; supports data segregation in hosted environments.
• OKC_ROLE_SOURCES_PK — the primary key constraint on (RLE_CODE, BUY_OR_SELL, START_DATE).
• OKC_ROLE_SOURCES_U1 — the unique index on (RLE_CODE, BUY_OR_SELL, START_DATE, ZD_EDITION_NAME).
• OKC_K_ROLES and related contract role tables in the OKC schema, which consume role codes resolved through this configuration.
• HZ_PARTYS and PO_VENDORS — the principal underlying party and supplier sources referenced indirectly through the object code, as illustrated in the documented Customer/Vendor example.

The table resides in the APPS_TS_SEED tablespace with PCT FREE 10, consistent with its role as seed/reference configuration rather than high-volume transactional data.