Search Results update_cs_data

Overview

CS_PARTYMERGE_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Service (CS) module family and, as its name suggests, supports the merge of Trading Community Architecture (TCA) party records by propagating the resulting changes into Service-owned data. When two parties (for example, duplicate customers, contacts, or employees) are consolidated through Oracle's Party Merge process, the reference data held against those parties in dependent applications must be updated so that transactions, service requests, and contact assignments continue to resolve to the surviving party. CS_PARTYMERGE_PKG provides the Service-side implementation of that post-merge data fix-up.

The package is classified as OTHER in the ETRM repository rather than as a public or private API, indicating that it is an internal, seed-data-driven object invoked by the Party Merge infrastructure rather than a general-purpose programming interface. Its header carries the identifier cssrpmns.pls and a noship designation, which indicates that the file was not shipped to customer sites as a standalone script but exists as part of the installed application schema.

Key Procedures and Functions

The package exposes a single documented procedure:

• UPDATE_CS_DATA — The core routine of the package. It performs the Service-module data updates associated with a party merge batch. The procedure accepts a batch identifier and a concurrent request identifier, and returns a status value to the caller. The batch identifier correlates the call with the running Party Merge process, while the request identifier allows the procedure's activity and outcome to be tied back to the concurrent request under which the merge is executing. The output status parameter communicates success or failure back to the invoking program, allowing the merge framework to determine whether the Service-side updates completed cleanly.

No additional procedures or functions are documented in the ETRM metadata, and the package is not referenced by any other package, confirming that it is a terminal consumer of the Party Merge event rather than a reusable service called by other PL/SQL code.

Tables Accessed

The package operates against the following tables, accessed through APPS synonyms:

• HZ_MERGE_PARTIES — The TCA table that records the source and target parties involved in a merge. The procedure reads this to determine the party relationships it must reconcile.
• HZ_MERGE_PARTY_LOG — The TCA audit trail of merge activity. Entries here drive or record the progress of the merge processing performed by the procedure.
• CS_INCIDENTS_ALL_B — The base table for Service Requests (incidents). Records referencing a merged (source) party must be repointed to the surviving party.
• CS_ESTIMATE_DETAILS — Service estimate lines that may carry party or contact references requiring update.
• CS_HZ_SR_CONTACT_POINTS — The association between service requests and TCA contact points; these links must be preserved and reassigned when parties are merged.
• CS_SR_CONTACTS_EXT — The extension table holding additional contact information for service requests, also subject to reassignment.
• PLITBLM — A standard Oracle Applications PL/SQL table (index-by table) type used internally by the procedure, typically as a PL/SQL table of numbers for collecting and iterating over sets of identifiers during bulk processing.

Usage Notes

CS_PARTYMERGE_PKG is invoked automatically as part of the TCA Party Merge concurrent process. When an administrator or data steward submits the Party Merge program to consolidate duplicate parties, the merge framework calls registered, application-specific handlers in sequence, and CS_PARTYMERGE_PKG.UPDATE_CS_DATA is the Service handler for that sequence. It is not intended to be called directly from a form, personalization, or custom concurrent program, and doing so without a valid Party Merge batch would produce no meaningful result. Because the procedure relies on the batch and request identifiers to scope its work, any custom invocation must supply identifiers created by the merge framework itself. On EBS 12.1.1 and 12.2.2 the object is present in the APPS schema with the same structure; the primary operational consideration is that the Service data updates run within the larger merge transaction, so failures returned through the status parameter should be investigated using the merge log before the batch is retried or reversed.