Search Results validate_k_party_role

Overview

OKC_CONTRACT_PARTY_PUB is the public (PUB-classified) PL/SQL API package for managing contract party information within the Oracle Contract Core (OKC) module of Oracle E-Business Suite. In EBS 12.1.1 and 12.2.2, OKC supplies the underlying infrastructure for Oracle Contracts and related modules such as Service Contracts, where parties (customers, contacts, and other role assignments) are associated with a contract header or version. This package exposes a stable, supported interface through which forms, concurrent programs, and custom extensions can create, maintain, validate, and lock those party and role relationships without directly manipulating the base tables.

The package source carries the header identifier OKCPCPLS.pls (revision 120.0, dated 2005) and is owned by APPS. It declares complex entity object subtype aliases drawn from the private package OKC_CONTRACT_PARTY_PVT — specifically ctcv_rec_type, ctcv_tbl_type, cplv_rec_type, and cplv_tbl_type — along with global record variables used for internal state. This layered design of a private implementation package plus a public wrapper is the standard ETRM pattern: the private package encapsulates business logic and table access, while the public package defines the supported API surface.

Key Procedures and Functions

The package exposes 21 documented procedures that fall into four functional families.

• Contact operations: CREATE_CONTACT and UPDATE_CONTACT each exist in single-record and table (bulk) overloads, accepting either a ctcv_rec_type or a ctcv_tbl_type. DELETE_CONTACT removes a contact association, LOCK_CONTACT obtains a locking handle to prevent concurrent modification, and VALIDATE_CONTACT performs business-rule validation of contact data prior to commit.
• Key party role operations: CREATE_K_PARTY_ROLE, UPDATE_K_PARTY_ROLE, and DELETE_K_PARTY_ROLE maintain role assignments linking a party to a contract entity. LOCK_K_PARTY_ROLE acquires a lock, and VALIDATE_K_PARTY_ROLE — the procedure the user searched for — validates a key party role record against contract party business rules before it is persisted or accepted.
• Language support: ADD_LANGUAGE registers an additional language (translation) for contract party data in a multi-lingual installation.
• Standard API conventions: The contact procedures follow the ETRM public API signature convention, carrying p_api_version, p_init_msg_list (defaulting to OKC_API.G_FALSE), and the output parameters x_return_status, x_msg_count, and x_msg_data for standardized error reporting, together with IN/OUT entity records.

Tables Accessed

Per the documented metadata, the package references the APPS synonym PLITBLM. PLITBLM is the standard Oracle Applications multi-lingual base table used for translated columns; OKC_CONTRACT_PARTY_PUB accesses it in support of language-dependent attribute storage and the ADD_LANGUAGE operation. Because the package operates through PL/SQL record subtypes defined in OKC_CONTRACT_PARTY_PVT, the bulk of its insert, update, and delete activity against the underlying contract party and party-role tables is delegated to that private package. The public layer therefore functions primarily as a validating, locking, and error-handling façade rather than a direct table manipulator.

Usage Notes

OKC_CONTRACT_PARTY_PUB is a server-side API and is not itself an end-user screen or concurrent program. It is invoked from Oracle Forms (notably the Contracts and Service Contracts party/contact windows), from other concurrent or batch processes, and from customer-written PL/SQL extensions that need to add or maintain contract parties and roles in a supported manner. The metadata records that the package is referenced by 25 other packages, confirming its role as a shared dependency within the OKC and adjacent modules.

Because VALIDATE_K_PARTY_ROLE and VALIDATE_CONTACT are exposed independently of the create and update routines, callers can perform pre-validation or combine validation with locking (LOCK_K_PARTY_ROLE) to implement safe, transactional updates. All callers must inspect x_return_status and, on failure, retrieve details via x_msg_count and x_msg_data, following the standard ETRM error-handling contract. Direct DML against the underlying contract party tables should be avoided in favor of this public API to preserve validation, locking, and multi-lingual integrity.