Search Results qp_cust_merge




Overview
Explore in AI Chat

Overview

QP_CUST_MERGE is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the API classification category "OTHER." Its name reflects its core purpose: supporting customer merge operations within the Oracle Advanced Pricing (QP) module. In Oracle EBS, when two customer records (parties, accounts, or sites) are merged through the Trading Community Architecture (TCA) customer merge process, dependent transactional and reference data across many modules must be reconciled so that references to the surviving (merge-to) customer replace references to the obsolete (merge-from) customer. QP_CUST_MERGE handles the Advanced Pricing side of this reconciliation, specifically the qualifiers and agreements that point to customer entities.

The package was specifically revised under Bug 8399386, as indicated by the header comment dated 2009 and the inclusion of the Check_Duplicate procedure. This suggests a targeted enhancement to guard against creating duplicate qualifier attribute values during or as part of the merge workflow. The package is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, which is consistent with many EBS utility packages invoked through standard APPS connectivity.

Key Procedures and Functions

  • CHECK_DUPLICATE — A procedure that assesses whether a given qualifier attribute value already exists for a specified qualifier. It accepts a qualifier identifier and a qualifier attribute value and is intended to detect duplicate condition records that could arise when pricing qualifiers referencing a merged customer are updated. This procedure was introduced or modified in support of Bug 8399386, providing a validation safeguard during the merge.
  • MERGE — The primary driver procedure. It accepts a request identifier, a set number, and a process mode, and orchestrates the update of Advanced Pricing entities (qualifiers and agreements) so that references to the merge-from customer are redirected to the merge-to customer. The set number parameter indicates the pricing context (for example, the pricing/customer set), and the process mode governs whether the routine runs in a validation or execution mode. The request identifier supports tracking and logging, consistent with concurrent-request-driven processing.

Tables Accessed

  • QP_QUALIFIERS — Stores the pricing qualifier definitions whose attribute values (customer references) are inspected via Check_Duplicate and reassigned during Merge.
  • OE_AGREEMENTS_B — Holds pricing agreements associated with customers; these agreement records are updated to point to the surviving customer.
  • RA_CUSTOMER_MERGES and RA_CUSTOMER_MERGE_HEADERS — The Receivables customer merge tables that define the merge-from/merge-to relationship and the merge request being processed.
  • HZ_CUSTOMER_MERGE_LOG and HZ_CUSTOMER_MERGE_LOG_S — TCA merge log tables used to record the outcome and history of merge activity, enabling audit and diagnostics.
  • PLITBLM — A standard EBS PL/SQL index-by table structure used for in-memory collections, typically for buffering identifiers during processing.

Usage Notes

QP_CUST_MERGE is not intended for direct end-user invocation. It is called from the TCA / Receivables customer merge framework, which invokes registered merge routines across product modules when a customer merge is submitted. The MERGE procedure is typically executed in a concurrent-process context, receiving the merge request identifier and processing in the mode dictated by the calling framework. The CHECK_DUPLICATE procedure is used internally to validate qualifier attribute values and prevent duplicate pricing conditions.

Because the package is documented as OTHER rather than a published open API, it should be treated as an internal utility. The metadata indicates it is referenced by zero other packages, reinforcing that it is invoked by external frameworks rather than by other PL/SQL APIs. Custom developers should avoid calling it directly; modifications to pricing qualifiers or agreements on merge are best driven through the standard customer merge concurrent programs. Any customization should account for the AUTHID CURRENT_USER behavior and the fact that the package was last updated to address duplicate-handling logic.