Search Results number_tbl

Overview

CS_PARTYMERGE_PKG is a service-oriented PL/SQL package in the Oracle E-Business Suite Customer Service (CS) module. Its business purpose is to reconcile and repoint Service Request (SR) and SR-related transaction data when two trading partners (parties) are merged through Oracle's Trading Community Architecture (TCA) party merge process. When the HZ_MERGE_PARTIES framework combines a "from" party into a "to" party, dependent records such as incidents, estimate details, contacts, contact points, and bill-to/ship-to site references must be re-keyed so that they continue to resolve to the surviving party. CS_PARTYMERGE_PKG encapsulates that normalization logic, which is executed in batch against a specific merge batch and concurrent request.

As reflected in its package header, the package is created in the APPS schema and is classified as an "OTHER" API (not a standard public interface API), meaning it is intended principally for internal, framework-driven invocation rather than direct customer callout. The source header revision indicates a 12.1.1-era build (120.2.12010000.2), and the object remains catalogued under 12.2.2 with a single documented procedure, UPDATE_CS_DATA.

Key Procedures and Functions

• UPDATE_CS_DATA — The sole documented procedure and the primary entry point for the package. It accepts a merge batch identifier and a concurrent request identifier, and returns an out status flag indicating the outcome of the update. It drives the party-merge data fix for Customer Service entities, applying the from-party to to-party substitutions to the affected SR and charge records and reporting success or failure through the out parameter.
• log — A private helper (declared in the package body, not part of the documented public API) that writes messages to the concurrent program log via FND_FILE, supporting the standard 'NEWLINE' convention used throughout this package.

Tables Accessed

The package operates over the following documented tables, which together represent the SR and TCA merge surface:

• CS_INCIDENTS_ALL_B — the base Service Request / incident table. Party and contact references on incidents are re-pointed from the merged (from) party to the surviving (to) party.
• CS_ESTIMATE_DETAILS — SR estimate/charge lines carrying party-derived identifiers, updated for the same reason.
• CS_SR_CONTACTS_EXT — SR contact extension data whose contact and party references are reconciled.
• CS_HZ_SR_CONTACT_POINTS — contact point records (e.g., phone, e-mail) linked to SR contacts, updated so they continue to resolve to the correct party/contact.
• HZ_MERGE_PARTIES — the TCA merge definition table, read to obtain the from/to party mapping that drives all substitutions.
• HZ_MERGE_PARTY_LOG — the merge audit/log table used to record merge activity and status.
• PLITBLM — the PL/SQL table of ROWIDs (RowID mapping table) used by the TCA merge framework to track affected rows.

Internally, UPDATE_CS_DATA populates multiple BINARY_INTEGER-indexed NUMBER_TBL collections (surfaced when searching "number_tbl"), including incident, estimate detail, customer, from/to party, bill-to/ship-to party, contact, and site identifier tables, declaring them alongside a ROWID_TBL. These PL/SQL tables buffer the keys to be updated before the DML is issued.

Usage Notes

CS_PARTYMERGE_PKG is normally invoked as part of the TCA party merge (Trade Management / Customers) "Merge Parties" concurrent program or the associated merge worker framework, rather than from a form or user-facing page. The framework passes the merge batch and concurrent request identifiers; UPDATE_CS_DATA then performs the set-based updates and returns a status used by the framework to decide whether the merge step succeeded. The package is not referenced by other packages in the documented metadata (0 dependents), confirming its position as a leaf-level worker. Customizations should avoid calling UPDATE_CS_DATA directly, since bypassing the TCA batch context can leave the merge log (HZ_MERGE_PARTY_LOG) and dependent rows inconsistent; all updates should flow through a genuine party-merge batch so the from/to mappings in HZ_MERGE_PARTIES remain authoritative.