Search Results get_party_contact_lov_sql




Overview
Explore in AI Chat

Overview

OKL_VP_JTF_PARTY_NAME_PUB is a public PL/SQL API package in the Oracle E-Business Suite Applications (APPS) schema that exposes party-name and party-role resolution services for Oracle Contracts and Oracle Lease Management (OKL) contract data. Its principal business purpose is to retrieve the parties attached to a contract or contract line, and to resolve the display name and description associated with a given party role for a specified contract object. As part of the OKL vertical "VP" (public API) layer, it is classified as a PUB package, meaning it is intended for external invocation by other Oracle modules, forms, and customer extensions rather than being restricted to internal use. The package delegates the business logic to its private counterpart, OKL_VP_JTF_PARTY_NAME_PVT, and exposes only the supported entry points. Subtypes such as party_tab_type are inherited from the private package, allowing callers to work with the same collection structures returned by the underlying implementation.

Key Procedures and Functions

  • GET_PARTY — Documented as the primary API, "Get_Party." It fetches all parties attached to a contract or line and returns them in a table (party_tab_type). The metadata documents two overloaded forms: one accepting a contract header identifier and line identifier with a role code and intent, returning the party collection; and a second form that returns the name and description of a single party role for a given object1_id1 and object2_id2 pair.
  • GET_PARTY_NAME — A function that returns the party name for a supplied role code, intent, and the object identifiers id1 and id2, suitable for inline SQL or expression use.
  • GET_CONTACT — Retrieves contact information for a party role associated with a contract object, returning the resolved identifiers, name, and description.
  • GET_PARTY_CONTACT_NAME — Resolves the name of a party contact in the context of the same role and identifier scheme.
  • GET_PARTY_LOV_SQL — Supplies the SQL statement used to populate a List of Values (LOV) of parties, enabling forms and custom UIs to present a consistent, filtered party selection list.
  • GET_PARTY_CONTACT_LOV_SQL — Supplies the analogous LOV SQL for party contacts, mirroring the party LOV behavior.

All documented procedures follow the standard EBS API convention: an API version parameter, an initialization flag (p_init_msg_list, defaulting to OKC_API.G_FALSE), the standard return status and message-count/message-data output parameters, role and intent inputs, and identifier inputs or outputs.

Tables Accessed

The ETRM metadata records no explicit base tables for this package; access is achieved through APPS synonyms and is largely encapsulated in the private package OKL_VP_JTF_PARTY_NAME_PVT. The role code parameter is declared against OKC_K_PARTY_ROLES_V.rle_code, indicating that the package reads the Contracts party-roles view to validate and resolve the role supplied by the caller. Party names and descriptions are resolved from the JTF party/contact structures referenced by the package name, while contract and line context is derived from the chr_id and cle_id identifiers. Because the package is a thin public wrapper, all direct SQL against underlying party, contact, and contract tables is performed in the private layer.

Usage Notes

This package is typically invoked when an application or report must display, validate, or select the party associated with a contract or contract line. Typical callers include Oracle Forms attached to the Contracts and Lease Management flows, concurrent programs that render contract party information, and custom extensions that need a supported, upgrade-safe method of resolving party names instead of querying base tables directly. The LOV SQL procedures are used to build dynamic LOV queries in the user interface. The ETRM metadata notes that the package is referenced by three other packages, confirming its role as a shared building block within the OKL public API family. Callers should always check x_return_status and process x_msg_count/x_msg_data through the standard EBS error-handling stack, and should pass a valid API version and role code to ensure correct resolution.