Search Results cs_incidents




Overview
Explore in AI Chat

Overview

CSP_CMERGE_BB8 is a member of the CSP_CMERGE_BB* family of merge packages shipped with Oracle E-Business Suite and delivered under the APPS schema with AUTHID CURRENT_USER. Its single documented purpose is to serve as the main merge block for the CS_INCIDENTS table during a customer merge operation. Oracle's customer merge facility (Customer Merge, frequently accessed through the Trading Community Architecture and the Receivables merge programs) consolidates duplicate or redundant customer records into a single surviving customer. When the merge is committed, every dependent table that carries a customer identifier, site identifier, or related party reference must be re-pointed from the duplicate (merge-from) customer to the surviving (merge-to) customer. CSP_CMERGE_BB8 is the component responsible for performing that re-pointing for the service incident records stored in CS_INCIDENTS.

The package is intentionally narrow in scope: it does not itself define merge rules, validate merge eligibility, or determine the surviving party. Those decisions are made by the customer merge driver, which supplies a request identifier, a set number, and a processing mode to each merge block in turn. CSP_CMERGE_BB8 occupies one slot in that orchestration chain, handling the incident table and nothing else.

Key Procedures and Functions

The documented package specification exposes exactly one public procedure, MERGE, which takes three parameters: a request identifier (req_id), a set number (set_number), and a processing mode (process_mode). The request identifier ties the execution to a specific customer merge batch, while the set number allows the merge engine to partition work into manageable batches. The processing mode distinguishes between a preliminary or validation pass and the actual update pass, an important distinction in merge processing because validation must succeed before destructive updates are applied.

The header comments enumerate a fixed internal call sequence that MERGE follows. MERGE first invokes CS_MERGE_BILL_TO_SITE_ID, then CS_MERGE_INSTALL_SITE_ID, then CS_MERGE_SHIP_TO_SITE_ID, then CS_MERGE_CUSTOMER_ID, and finally CS_CHECK_MERGE_DATA. These subordinate procedures perform the site-identifier and customer-identifier substitutions on the incident rows, with the final CS_CHECK_MERGE_DATA call verifying that the merge produced a consistent result for the affected records. The ordering matters: site identifiers are updated before the customer identifier, and the consistency check is deferred until all updates are complete.

Tables Accessed

Two tables are documented as referenced through APPS synonyms. The first is CS_INCIDENTS, the service incident table that stores customer service requests, complaints, and interaction records. This is the target of the merge: its BILL_TO_SITE_ID, INSTALL_SITE_ID, SHIP_TO_SITE_ID, and CUSTOMER_ID columns are the values being rewritten to point at the surviving customer. The second is RA_CUSTOMER_MERGES, the Receivables customer merge audit table that records merge history and the mapping between merge-from and merge-to parties. CSP_CMERGE_BB8 consults this table to determine which customer and site identifiers should replace the original values, and it may also contribute status information back to the merge record so the overall merge run can track progress.

Usage Notes

CSP_CMERGE_BB8 is not intended for direct invocation by end users or by custom application code. It is called by the Oracle customer merge infrastructure as part of the standard merge execution path, alongside the other CSP_CMERGE_BB* blocks that cover different table groupings. In practice the package is reachable from the Customer Merge concurrent program and from the merge-related forms in the Service and Trading Community modules, all of which pass the request identifier, set number, and processing mode supplied by the merge driver.

Because the package runs with AUTHID CURRENT_USER and operates on live transactional data, any custom code that calls it must supply a valid merge request already registered in RA_CUSTOMER_MERGES; otherwise the subordinate procedures will find no mapping data and the run will fail the CS_CHECK_MERGE_DATA verification. Organizations extending the merge process should treat this package as a reference implementation and avoid modifying it in place, since it is a protected Oracle-owned object and is patched as part of the EBS code line.