Search Results oe_sets_merge

Overview

APPS.OE_CUST_MERGE is the Oracle Order Management (ONT) product-level handler for the Customer Merge process in Oracle E-Business Suite 12.1.1 and 12.2.2. Customer Merge is a Trading Community Architecture (TCA) utility that consolidates a duplicate customer (or party) record into a surviving "merge-to" customer. Because order management data is heavily denormalized and touches transactional, defaulting, and workflow tables, TCA delegates the ONT-specific portion of the merge to this package. The package's single public entry point, Merge, orchestrates a series of area-specific internal procedures so that all Order Management references to the obsolete customer are reassigned to the surviving customer.

The package header carries a version marker of 120.1.12010000.1, indicating it is a long-standing component of the ONT code line rather than a release-specific addition, and it is classified as a non-API ("OTHER") utility used internally by the EBS application rather than by external integrators.

Key Procedures and Functions

The package exposes one public procedure and nine internal procedures, all sharing the same Req_Id, Set_Num, and Process_Mode signature.

• Merge — The main driver. It dispatches to the internal procedures so that each functional area is processed in turn for the given customer merge request.
• OE_Attachment_Merge — Handles Order Management attachment records and related attachment rules tied to the merged customer.
• OE_Defaulting_Merge — Updates defaulting rules, conditions, and attribute definitions associated with the customer.
• OE_Constraints_Merge — Processes customer constraint and customer item settings data.
• OE_Sets_Merge — Reassigns Order Management sets that reference the merged customer.
• OE_Drop_Ship_Merge — The procedure relevant to the oe_drop_ship_merge search term. It processes drop-ship relationships, including the drop-ship sourcing and address information held for the customer, so that in-flight and historical drop-ship orders point to the surviving customer.
• OE_Ship_Tolerance_Merge — Reassigns shipping tolerance definitions owned by the customer.
• OE_Hold_Merge — Updates order hold definitions and hold release information linked to the customer.
• OE_Order_Merge — Performs the core reassignment of order headers, lines, and blanket agreements to the surviving customer.
• OE_Workflow_Merge — Updates Oracle Workflow item attributes and activity records that reference the merged customer, preserving the order flow status.

Tables Accessed

The package reads and writes a broad set of ONT and TCA tables through APPS synonyms. Transactional objects include OE_ORDER (via OE_Order_Merge logic), OE_BLANKET_HEADERS, OE_BLANKET_HEADERS_ALL, OE_BLANKET_HEADERS_HIST, OE_BLANKET_LINES, OE_BLANKET_LINES_ALL, and OE_BLANKET_LINES_HIST, all of which carry the customer or ship-to identifier. Configuration and rule tables include OE_ATTACHMENT_RULE_ELEMENTS, OE_CUST_ITEM_SETTINGS, OE_DEF_ATTR_DEF_RULES, OE_DEF_CONDN_ELEMS, and OE_SHIP_TOLERANCE type references. Customer-facing tables include HZ_CUSTOMER_PROFILES, AR_SYSTEM_PARAMETERS, and the TCA merge tracking tables HZ_CUSTOMER_MERGE_LOG and HZ_CUSTOMER_MERGE_LOG_S. OE_CUST_MERGES_GTT is a global temporary table used to stage and iterate the records to be merged within the session.

Usage Notes

OE_CUST_MERGE is not intended for direct invocation. It is called by the TCA Customer Merge concurrent program (typically launched from the Customers form or the Customer Merge responsibility) as part of the multi-product merge sequence. The Req_Id identifies the merge batch, Set_Num identifies the merge set within that batch, and Process_Mode controls whether the run performs validation only or commits changes. Because it is referenced by one other package and is registered as a non-API object, customizations should avoid calling it directly; instead, use the supported TCA Customer Merge UI or the TCA merge APIs, and allow Oracle to drive OE_CUST_MERGE internally. Customers upgrading between 12.1.1 and 12.2.2 should note that the package header date (2008) precedes the 12.2 documentation set, but the 12.2.2 ETRM metadata confirms the same ten procedures remain in place.