Results for “orig_system_source_code”

24 results




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

Overview

OKC_K_PARTY_ROLES_B is the foundational base table within the Oracle Contracts Core (OKC) module that records the three-way relationship between a contract, the parties associated with that contract, and the roles those parties play during contract participation. In Oracle EBS 12.1.1 and 12.2.2, this table serves as the central repository for party-role assignments across the complete contract lifecycle, including authoring, negotiation, approval, fulfillment, and termination phases. Every party that participates in a contract — whether a customer, supplier, internal organization, contact, or third-party beneficiary — is captured as a row in this table, linked to a specific contract header or contract line.

From a Data Vault modeling perspective, the mined foreign-key structure suggests this table functions as a hub. It holds the durable business keys and serves as the integration point that multiple surrounding tables — including OKC_CONTACTS, OKL_K_PARTY_ROLES, OKC_RG_PARTY_ROLES, and OKL_PARTY_PAYMENT_DTLS — reference through the CPL_ID surrogate. This hub-like behavior makes OKC_K_PARTY_ROLES_B one of the most heavily referenced objects in the OKC schema.

Key Information Stored

The table contains 43 documented columns in the 12.2.2 physical schema. The most operationally significant are listed below.

  • ID — Surrogate primary key defined by the OKC_K_PARTY_ROLES_B_PK constraint and the U1 unique index. This value is the CPL_ID referenced by nearly every downstream child table.
  • CHR_ID — Foreign key to OKC_K_HEADERS_B, identifying the contract header to which the party-role assignment belongs.
  • CLE_ID — Foreign key to OKC_K_LINES_B, used when the party-role assignment is scoped to a specific contract line rather than the header.
  • CPL_ID — Self-referencing foreign key that supports hierarchical party-role relationships (for example, a sub-party associated with a parent party).
  • RLE_CODE — Role code identifying the function the party performs, such as buyer, seller, bill-to, ship-to, or approver.
  • JTOT_OBJECT1_CODE — Foreign key to JTF_OBJECTS_B that classifies the type of object being referenced for the party relationship.
  • OBJECT1_ID1 and OBJECT1_ID2 — The composite identifier of the actual party record in the originating system, interpreted in conjunction with JTOT_OBJECT1_CODE.
  • PRIMARY_YN — Flag indicating whether this party-role combination is the primary assignment for the contract.
  • CUST_ACCT_ID and BILL_TO_SITE_USE_ID — Customer account and bill-to site use references, linking contract parties into Oracle Receivables and Oracle TCA structures.
  • ORIG_SYSTEM_ID1, ORIG_SYSTEM_REFERENCE1, ORIG_SYSTEM_SOURCE_CODE — Denormalized origin keys that support reconciliation with external or upstream source systems.
  • DNZ_CHR_ID — Denormalized contract header identifier, typically populated for query performance on header-level lookups.
  • SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, enforcing multi-org and data-security access rules.
  • Standard Who columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the OBJECT_VERSION_NUMBER for optimistic locking.

The unique index U1 enforces the surrogate ID, while U2 (RLE_CODE, JTOT_OBJECT1_CODE, OBJECT1_ID1, OBJECT1_ID2, CHR_ID, CLE_ID) acts as the documented business-key candidate, preventing duplicate role assignments of the same party to the same contract scope.

Common Use Cases and Queries

Typical applications of OKC_K_PARTY_ROLES_B include contract party reporting, role-based security determination, integration with leasing (OKL) and receivables, and audit of party changes over time.

  • List all parties for a contract header: SELECT p.ID, p.RLE_CODE, p.OBJECT1_ID1, p.PRIMARY_YN FROM OKC.OKC_K_PARTY_ROLES_B p WHERE p.CHR_ID = :header_id;
  • Find the primary bill-to party: join CUST_ACCT_ID and BILL_TO_SITE_USE_ID to Oracle TCA tables filtered by RLE_CODE and PRIMARY_YN = 'Y'.
  • Trace downstream dependencies: join to OKL_K_PARTY_ROLES via OKL_K_PARTY_ROLES.ID = OKC_K_PARTY_ROLES_B.ID to see leasing-specific party data.
  • Contact lookups: join OKC_CONTACTS on CPL_ID to retrieve contact details associated with each contract party role.
  • Party change history: join to OKC_CHANGE_PARTY_ROLE on CPL_ID to audit role modifications over time.

Related Objects

  • OKC_K_HEADERS_B — Parent contract header referenced via CHR_ID.
  • OKC_K_LINES_B — Contract line referenced via CLE_ID for line-level party roles.
  • OKC_CONTACTS — References CPL_ID; stores contact details for contract parties.
  • OKC_ITEM_PARTYS_B — References CPL_ID; captures item-level party involvement.
  • OKC_RG_PARTY_ROLES — References CPL_ID; rules-based party role assignments.
  • OKC_CHANGE_PARTY_ROLE — References CPL_ID; change tracking for party roles.
  • OKL_K_PARTY_ROLES — References ID; the leasing-side shadow of contract parties.
  • OKL_PARTY_PAYMENT_DTLS and OKL_QUOTE_PARTIES — Both reference CPL_ID from leasing and quoting flows.
  • JTF_OBJECTS_B and FND_SECURITY_GROUPS — Reference lookups for object classification and data security.