Search Results org_system_reference

Overview

ARP_CMERGE_ARCUS is an Oracle Receivables package body (APPS-owned) that participates in the customer merge process within Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its central role is the migration of contact and contact point data from a "from" (source) customer, party, or account to a "to" (target) customer when accounts are merged. The header comment /*$Header: ARHCMGNB.pls 120.52.12020000.3 2013/03/01 08:42:47 vsegu ship $*/ identifies the source file and the patch level at which it was shipped, confirming this is a shipped, supported component rather than a customer extension.

The package is classified as OTHER in the ETRM API classification. This classification indicates that ARP_CMERGE_ARCUS is not a public, customer-callable API with a documented contract; rather it is an internal worker package invoked by the broader customer merge framework. The "ARCUS" suffix reflects its association with the customer (AR) merge logic, specifically the archiving and consolidation of contact-related records during merge operations.

Key Procedures and Functions

ETRM documents five procedures and functions for this package:

• MERGE — The primary entry point that orchestrates the customer merge for contact data. It drives the migration of contacts and contact points from the source account and party to the target, coordinating the lower-level routines.
• CREATE_SAME_SITES — Creates site-level records that are identical between the source and target customers, ensuring site associations remain consistent after the merge.
• CREATE_TEMPORARY_TABLE — Builds a temporary staging table used to hold intermediate merge data during processing, supporting set-based handling of large contact volumes.
• DELETE_ROWS — Removes processed or superseded rows from staging or target structures once migration is complete, keeping the merge atomic and clean.
• MERGE_HISTORY — Records merge history and audit information so that the merge can be traced and, where applicable, reversed or reported.

The source excerpt additionally reveals internal helper routines such as do_merge_contacts, do_cust_merge_contacts, do_site_merge_contacts, do_copy_contact_points, and the duplicate-detection functions check_org_contact_dup and check_contact_point_dup. These operate at account, site, and contact levels and are not part of the documented public surface.

Tables Accessed

ARP_CMERGE_ARCUS reads and writes the following documented tables through APPS synonyms, all from the HZ (Trading Community Architecture) schema:

• HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNTS_M — Core customer account records and their multi-org (_M) counterparts.
• HZ_CUST_ACCT_SITES, HZ_CUST_ACCT_SITES_ALL, HZ_CUST_ACCT_SITES_ALL_M — Account site definitions, including the _ALL multi-org and _M variants used for site-level merging.
• HZ_CUST_ACCT_RELATE_ALL, HZ_CUST_ACCT_RELATE_ALL_M — Account relationship records migrated during merge.
• HZ_CUST_ACCOUNT_ROLES, HZ_CUST_ACCOUNT_ROLES_M — Role assignments for contacts associated with the account.
• HZ_CONTACT_POINTS and HZ_CUST_CONTACT_POINTS — Contact point records (phone, email, and similar) copied or migrated between parties.
• HZ_CUSTOMER_PROFILES, HZ_CUSTOMER_PROFILES_M — Customer profile data tied to the merged accounts.
• HZ_CUSTOMER_MERGE_LOG, HZ_CUSTOMER_MERGE_LOG_S — Merge log and its sequence, used to record the outcome of each merge operation.

Usage Notes

ARP_CMERGE_ARCUS is not intended for direct invocation by customers or custom code. It is called by the Oracle Receivables customer merge framework — typically through the Customer Merge concurrent program or the corresponding merge form — and is referenced by one other package, indicating a tightly coupled dependency within the merge subsystem. Because the package manipulates core HZ customer, site, contact, and relationship data, it should only be executed as part of the sanctioned merge workflow, which enforces validation of the source and target accounts before processing. Customizations should not call these procedures directly; organizations requiring bespoke merge behavior should use documented public APIs such as the HZ customer merge interfaces instead.