Results for “okc_change_party_role”

50+ results




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

Overview

The OKC_CHANGE_PARTY_ROLE table is a Contracts Core (OKC) transactional table that associates a Contract Party with a Change Request in Oracle E-Business Suite 12.1.1 and 12.2.2. Its stated purpose is to relate a contract party to a change request, effectively modeling the intersection between parties who hold defined roles on a contract and the change requests raised against that contract. The table resides in the OKC schema and holds VALID status in the data dictionary.

From a Data Vault modeling perspective, the mined FK structure suggests this table behaves as a link entity: it resolves a many-to-many relationship between contract change requests (OKC_CHANGE_REQUESTS_B) and contract party roles (OKC_K_PARTY_ROLES_B). Each row represents one such association, and the composite primary key naturally forms the link hash key. Reporting and integration layers that model ETRM data may treat OKC_CHANGE_PARTY_ROLE as a relationship/link table rather than as a descriptive hub or satellite.

Key Information Stored

The documented physical schema contains ten columns, of which the following are the most functionally significant:

  • CRT_ID — Change Request identifier; part of the composite primary key OKC_CHANGE_PARTY_ROLE_PK and a foreign key to OKC_CHANGE_REQUESTS_B. Identifies which change request the party role is attached to.
  • CPL_ID — Contract Party Role identifier; the second component of the composite PK, foreign keyed to OKC_K_PARTY_ROLES_B. Identifies the specific party-role assignment being linked.
  • ACCEPTANCE_DATE — The date on which the party-role association was accepted in the context of the change request; the only true business-attribute column beyond the key pair.
  • OBJECT_VERSION_NUMBER — Optimistic locking column used by the OAF/EO framework to detect concurrent updates.
  • SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, supporting multi-org/security-group data segregation.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard WHO-column auditability.

The primary key OKC_CHANGE_PARTY_ROLE_PK (CRT_ID, CPL_ID) and the unique index OKC_CHANGE_PARTY_ROLE_U1 (CRT_ID, CPL_ID) coincide, meaning the pair of foreign keys serves as both the surrogate and the business-key candidate: no additional uniqueness column exists. A change request can therefore reference a given party role only once.

Common Use Cases and Queries

The table is typically queried when auditing which parties were involved in — or affected by — a given contract change request, or conversely when tracing all change requests that touched a particular party role.

To list all party roles tied to a change request:

  • SELECT cpr.crt_id, cpr.cpl_id, cpr.acceptance_date FROM okc.okc_change_party_role cpr WHERE cpr.crt_id = :p_change_request_id;

To join through to the party role definition and the change request header:

  • Join CPL_ID to OKC_K_PARTY_ROLES_B and CRT_ID to OKC_CHANGE_REQUESTS_B, filtering by STATUS or contract number on the parent tables to produce change-impact reports.
  • Aggregate counts of party roles per change request to identify high-impact change requests during contract amendment cycles.

Because ACCEPTANCE_DATE is the only descriptive attribute, reporting most often focuses on existence and timing of party acceptance rather than on rich detail; supplementary descriptive data resides on OKC_K_PARTY_ROLES_B and OKC_CHANGE_REQUESTS_B.

Related Objects

  • OKC_CHANGE_REQUESTS_B — parent change-request header; joined via OKC_CHANGE_PARTY_ROLE.CRT_ID.
  • OKC_K_PARTY_ROLES_B — contract party role definition; joined via OKC_CHANGE_PARTY_ROLE.CPL_ID.
  • FND_SECURITY_GROUPS — security-group lookup; joined via SECURITY_GROUP_ID.
  • OKC_CHANGE_REQUESTS_TL — translated change-request text, often joined for reporting labels.
  • OKC_K_PARTY_ROLES_TL — translated party-role descriptions.
  • OKC_CHANGE_REQUEST_* DML APIs / OAF pages — programmatic and UI maintenance paths that insert and update rows in this table.

These relationships confirm the table's role as a junction binding change requests to party roles within the Contracts Core schema.