Results for “cs_systems”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CSP_CMERGE_BB3 is a PL/SQL package owned by the APPS schema that participates in the Oracle EBS customer merge infrastructure. Its defined role, as expressed in the package header, is to serve as "the main block for merging the cs_customer_products table." The package is part of a family of block-level merge programs (the "BB" naming convention) that the Oracle Customer Relationship Management and Order Management modules use to reconcile dependent tables whenever two customer records are combined into one surviving entity.

The package is declared with AUTHID CURRENT_USER, meaning its SQL statements execute with the privileges of the invoking user rather than the definer. This is significant in the customer merge context because merge processing is normally driven from the Trading Community Architecture (TCA) layer and must respect the calling application's security context. The header carries a legacy revision string ($Header: cscm103s.pls 115.0 99/07/16) that dates the source to the original CSP (Customer Support/Service) design lineage, positioning the package as a long-standing component that has survived largely unchanged through the 12.1.1 and 12.2.2 releases.

The package is classified as an "OTHER" API in ETRM, indicating that it is not a formally published public API but an internal worker invoked by the merge orchestration layer.

Key Procedures and Functions

ETRM documents a single procedure, MERGE, within this package. The procedure is the package's sole entry point and is designed to accept a request identifier, a set number, and a process mode, which allows the merge framework to track the batch job, partition the work into sets, and control whether the operation runs in validation or execution mode.

Inside MERGE, the package delegates the actual column-level reconciliation to a series of specialized merge procedures. The documented call sequence is as follows:

• CS_MERGE_BILL_TO_SITE_ID — reassigns the bill-to site identifier on affected customer product records.
• CS_MERGE_INSTALL_SITE_ID — reassigns the install site identifier.
• CS_MERGE_SHIP_TO_SITE_ID — reassigns the ship-to site identifier.
• CS_MERGE_CUSTOMER_ID — reassigns the customer identifier itself, completing the transition from the duplicate to the surviving customer.
• CS_CHECK_MERGE_DATA — performs post-update validation to verify that the merged rows are internally consistent and that no orphaned references remain.

This ordered sequence ensures that foreign key dependencies among the site and customer references are respected before the final validation step. The comment block explicitly identifies the target table of the operation as CS_SYSTEMS, which is the shipped nomenclature for the install-base table commonly surfaced as CS_CUSTOMER_PRODUCTS in later releases.

Tables Accessed

ETRM records two tables referenced through APPS synonyms: CS_SYSTEMS and RA_CUSTOMER_MERGES.

• CS_SYSTEMS — the primary subject of the merge. The procedure updates the customer, bill-to, ship-to, and install site columns on rows belonging to the losing customer so they point to the surviving customer.
• RA_CUSTOMER_MERGES — the controlling table for the customer merge process. It stores the merge request definition, the source and target customer identifiers, the current processing status, and the set/request identifiers that are passed into the MERGE procedure. CSP_CMERGE_BB3 reads this table to determine its scope of work and updates it to report completion.

Usage Notes

CSP_CMERGE_BB3 is not intended to be called directly by end users or by custom code. It is invoked indirectly through the Oracle Customer Merge concurrent program, which orchestrates a large series of block-level packages against the tables that reference customer identifiers. When a user submits the Customer Merge request from the Trading Community Architecture or from the Receivables/Order Management merge UI, the framework creates a row in RA_CUSTOMER_MERGES and then calls each applicable CSP_CMERGE_* package in turn.

Because the package carries AUTHID CURRENT_USER and depends on the session context established by the merge driver, developers extending the customer merge process should register any additional dependent table handling through the supported merge extension mechanisms rather than modifying this package. ETRM notes that the package is referenced by one other package, confirming its position as a leaf-level worker rather than an independently callable API.