Search Results cs_repairs




Overview

APPS.CSP_CMERGE_BB7 is a customer merge worker package used by Oracle E-Business Suite's Trading Community Architecture (TCA) customer merge infrastructure. It is one of a series of "block" packages (designated by the BB suffix and a sequence number) that collectively perform the deep, table-by-table updates required when two customer records are merged into a single surviving party. Within this framework, CSP_CMERGE_BB7 is specifically responsible for reconciling the CS_REPAIRS table—the Service (Field Service / Depot Repair) repository of repair orders—so that repair records previously tied to the merged (duplicate) customer are re-pointed to the surviving customer record.

The package resides in the APPS schema and is classified as OTHER in the API taxonomy, confirming it is an internal utility rather than a public, callable API. Its source header dates to 1999, reflecting its origin in the earlier Customer Service (CS) modules, yet the package remains referenced in EBS 12.1.1 and 12.2.2 through the TCA customer merge concurrent manager flow.

Key Procedures and Functions

The ETRM metadata documents a single entry point:

  • MERGE — The driver procedure for this merge block. It does not perform the row updates directly; instead it writes header and status messages to the merge log (using the ARP_MESSAGE utility) and delegates the actual work to an internal local procedure referenced in the body as CS_MERGE_CUSTOMER_ID, which performs the customer_id reassignment. MERGE accepts the standard merge parameters of request ID, set number, and process mode. The process_mode parameter distinguishes at minimum a LOCK phase—where the CS_REPAIRS table is locked and no data is changed—from the update/merge phase, allowing the merge framework to serialize access before any commits occur.
  • CS_MERGE_CUSTOMER_ID (internal, local to the body) — Invoked by MERGE to update the customer_id on repair records. It is not exposed as a documented API and is not called directly by external code.

Tables Accessed

The documented table references include RA_CUSTOMER_MERGES, the TCA/Receivables staging table that records and drives the merge of two customer records, providing the party mapping consumed by the merge blocks.

Per its embedded source documentation, the substantive target of the package is CS_REPAIRS, which stores field service and depot repair orders. The CS_MERGE_CUSTOMER_ID procedure updates the customer identifier on these rows so that historical and open repair transactions follow the surviving customer. The package thus reads merge mapping context and writes to CS_REPAIRS; it does not create or delete repair records.

Usage Notes

CSP_CMERGE_BB7 is not intended for direct invocation by end users, forms, or custom code. It is called by the TCA customer merge orchestrator—typically the Customer Merge concurrent program—which iterates through the numbered CSP_CMERGE_BB* blocks, passing the request ID, set number, and process mode. The ETRM metadata notes it is referenced by one other package, consistent with this orchestrated, chain-of-blocks design.

Because the merge runs in two modes, DBAs and support analysts reviewing a merge will see LOCK-phase log entries (in which CS_REPAIRS is locked and the message "The locking is done in block CSP_CMERGE_BB7" is written) followed by update-phase entries before the block reports completion. Any row locks or contention errors observed during a customer merge that reference CS_REPAIRS should be attributed to this package. When tracing the user search term rma_customer_id, note that CSP_CMERGE_BB7 updates the customer identifier on repair records in CS_REPAIRS; related RMA customer identifiers are handled by sibling merge blocks, and this package should not be modified or called out of sequence, as doing so would break the merge transaction's locking and commit boundaries.