Search Results validate_party

Overview

OKL_JTOT_CONTACT_EXTRACT_PUB is a public PL/SQL package in the Oracle E-Business Suite applications schema (APPS), classified as a PUB API and authenticated with AUTHID CURRENT_USER. Its source header identifies it as part of the OKL (Oracle Lease Management) module, with a revision history dating to 2003 (115.5). The package exists to service the JTOT contact extract integration flow — the interface by which contact and party-role information associated with lease contracts and lease lines is extracted and passed to external systems. It encapsulates the retrieval of party and contact records attached to contracts, contract lines, and invoice-related objects, and exposes that data through strongly typed PL/SQL record and table structures (party_rec_type and party_tab_type) rather than through raw SQL, insulating callers from the underlying OKC and OKL table structures.

Key Procedures and Functions

The package exposes six documented entry points:

• GET_PARTY — Returns party data for a given role code and intent. Two overloaded forms are visible in the source: one returns a table of party records for a contract or line (p_chr_id, p_cle_id, p_role_code, p_intent), while the other returns name and description attributes for a party role identified by object1_id1 and object1_id2. The query uses a default intent of 'S'.
• GET_CONTACT — Retrieves contact information associated with the contract or party role, complementing GET_PARTY for the extract pipeline.
• VALIDATE_PARTY — Performs validation logic against party records before they are extracted or persisted. This is the object the user searched for ("validate_party"). It is the guard routine that confirms a party role referenced on a contract or line is valid for the intended extract, so downstream consumers do not receive orphaned or inconsistent contact rows.
• DELETE_PARTY — Removes party role entries, typically invoked during re-extraction or cleanup of previously exported party data.

All procedures follow the standard EBS API convention: p_api_version in, p_init_msg_list in, x_return_status/x_msg_count/x_msg_data out for message-stack handling, with the G_API_TYPE constant '_PVT' and OKC_API.G_MISS_CHAR sentinels for unset attributes.

Tables Accessed

References are made through APPS synonyms. Contract and party structures are read from OKC_K_HEADERS_B, OKC_K_PARTY_ROLES_B, OKC_CONTACT_SOURCES, OKC_LINE_STYLES_B, OKC_ROLE_SOURCES, and OKC_SUBCLASS_ROLES. Lease-side data is drawn from OKL_K_HEADERS, OKL_K_LINES, OKL_TRX_AP_INVOICES_B, and OKL_TXL_AP_INV_LNS_ALL_B. Descriptive and reference data comes from FND_LOOKUP_VALUES, JTF_OBJECTS_B, AK_REGIONS, AK_REGION_ITEMS, and WF_PARAMETER_LIST_T. Together these support resolution of which parties and contacts belong to a contract or line, how roles are sourced, and how the extract output should be labeled.

Usage Notes

The package is referenced by three other packages, indicating it is invoked programmatically rather than driven directly by a form. It is best understood as a supporting API for the JTOT contact extract integration, called from custom extract code, concurrent programs, or other OKL packages that assemble lease contact feeds. Typical invocation is by contract header or line identifier plus role code, with results consumed into the party_tab_type collection. Because the validation routine is the searched object, custom code performing its own extract should call VALIDATE_PARTY before relying on any returned party row, and should honour the standard x_return_status/message-stack contract rather than assuming exceptions. Its signature dates from the 11i era and remains compatible in 12.1.1 and 12.2.2, though the source line marked "noship" and the accompanying metadata recommend confirming the currently installed version before integration.