Search Results pool_party_merge

Overview

OKE_PARTY_MERGE_PKG is a party merge handler package owned by APPS within the Oracle E-Business Suite Procurement family (OKE schema — Oracle Contracts). Its business purpose is to maintain referential integrity of contract data when two trading parties (typically suppliers or customers represented as TCA parties) are merged inside Oracle Receivables or Oracle Trading Community Architecture (HZ). During a party merge, a "from" party is consolidated into a "to" party, and every downstream application that stores a party_id foreign key must update its records. This package fulfills that responsibility for the Oracle Contracts (OKE) tables that reference party identifiers, ensuring that after the merge the contract records point to the surviving party and no orphaned references remain.

The package is registered as an API classification "OTHER" integration point, meaning it is not exposed as a callable public business API but is instead invoked internally by the party merge framework via the standard merge-handler contract. The header revision ($Header: OKEVPMGB.pls 115.5) indicates this code has been stable since the 11i era and is carried forward unchanged into 12.1.1 and 12.2.2.

Key Procedures and Functions

The package documents three procedures, each targeting a specific OKE table and following the identical merge-handler signature pattern (merge name, from/to primary id, from/to foreign key id, parent entity name, batch identifiers, and an OUT return status).

• POOL_PARTY_MERGE — Handles the party merge for the OKE_POOL_PARTIES table. This is the pool party association record, used to link a party to a contract pool. The procedure first checks whether the parent foreign key has changed; if p_from_fk_id = p_to_fk_id, it short-circuits, assigns p_to_id := p_from_id, and returns success without a DML statement. Otherwise it updates OKE_POOL_PARTIES, setting party_id to the surviving value and stamping last_update_date, last_updated_by, and last_update_login from HZ_UTILITY_PUB.
• FUNDING_PARTY_MERGE — Performs the equivalent merge maintenance for OKE_K_FUNDING_SOURCES, the base table holding funding source definitions on contracts. The same parent-unchanged short-circuit logic applies before the update is executed.
• FUNDING_PARTY_H_MERGE — The corresponding handler for OKE_K_FUNDING_SOURCES_H, the history (audit) table that shadows OKE_K_FUNDING_SOURCES. It propagates the party re-pointing into the historical rows so that audit trails remain consistent with the live data.

Tables Accessed

Three tables are referenced through APPS synonyms:

• OKE_POOL_PARTIES — Updated by POOL_PARTY_MERGE to replace the obsolete party_id with the surviving party_id.
• OKE_K_FUNDING_SOURCES — Updated by FUNDING_PARTY_MERGE, the live funding source records attached to contracts.
• OKE_K_FUNDING_SOURCES_H — Updated by FUNDING_PARTY_H_MERGE, preserving historical/audit consistency.

All DML is attribute-stamped using HZ_UTILITY_PUB, the standard utility that supplies the current user, login, and timestamp within the TCA merge session context.

Usage Notes

OKE_PARTY_MERGE_PKG is not invoked directly by end users. It is called by the TCA/HZ party merge concurrent process, which discovers registered merge handlers through the party merge handler registry and invokes each with the standardized parameter contract. The user search term "oke_contracts_unexpected_error" corresponds exactly to the error raised in this package's WHEN OTHERS exception handler: the code calls FND_MESSAGE.SET_NAME('OKE','OKE_CONTRACTS_UNEXPECTED_ERROR'), seeds the message tokens SQLcode and SQLerrm, adds the message via FND_MSG_PUB, and returns G_RET_STS_UNEXP_ERROR. Consequently, this error surfaces during party merge submission when an UPDATE on any of the three tables fails — most commonly due to a unique constraint violation, a locked row, or a missing/duplicate party reference. Diagnosis should proceed by extracting the SQLcode and SQLerrm tokens from the concurrent request log and inspecting the corresponding OKE rows for conflicting party_id values. Any customization of these handlers should preserve the parent-unchanged short-circuit to avoid unnecessary DML and the FND message convention so that merge error reporting remains intact.