Search Results check_duplicates

Overview

APPS.CS_SRCONTACT_PKG is a service request contact management package within the Oracle E-Business Suite Customer Service (Service) module. Its primary business function is to validate, persist, and audit the contact records associated with a Service Request (SR) — the contacts, parties, and contact points (such as phone, email, and other communication channels) that are linked to an incident. The package operates as an internal component of the Service Request API layer and is referenced by two other packages within the ETRM object repository. It is classified as an OTHER API and, as reflected by the noship header tag, is an internal (non-shipped as a public API) implementation object owned by the APPS schema.

Much of its validation logic centres on the check_duplicates procedure, which is the object most commonly searched for in relation to this package.

Key Procedures and Functions

• CREATE_UPDATE — The principal entry point for creating or modifying SR contact records. It coordinates the processing of the contact table passed in from the Service Request API and applies the resulting inserts and updates.
• PROCESS — The driver routine that orchestrates contact record handling, including the sequence of validation and persistence steps for the contacts supplied by the SR API.
• VALIDATE_CONTACT — Validates the supplied contact data. This procedure houses the duplicate detection logic, including check_duplicates, which determines whether an input contact conflicts with existing, non-updated contact records. A record is considered a duplicate when it shares the same contact type, party ID, contact point type, contact point ID, and party role code, and has overlapping start and end dates. On detection of a duplicate, the return status is set to error; otherwise it is set to success.
• PROCESS_G_MISS — Handles processing related to records flagged as missing (the "G_MISS" condition), ensuring continuity of contact data.
• POPULATE_CP_AUDIT_REC — Populates the contact point audit record structure, capturing the before/after image of contact point changes for audit purposes.
• CREATE_CP_AUDIT — Creates the audit entries for contact point modifications, writing the historical record to the audit table.

Tables Accessed

• CS_HZ_SR_CONTACT_POINTS / CS_HZ_SR_CONTACT_POINTS_S — The base and translated contact point tables that hold the SR contact points being validated and maintained.
• CS_HZ_SR_CONTACT_PNTS_AUDIT — The audit table written to by the audit procedures, preserving contact point change history.
• CS_INCIDENTS_ALL_B — The Service Request (incident) base table, used to associate contacts with the correct SR identifier.
• HZ_PARTIES and HZ_RELATIONSHIPS — TCA party and relationship tables, referenced to resolve party IDs and party role codes required for duplicate comparison.
• PER_ALL_PEOPLE_F — The HR people table, used to validate the contact person referenced by the SR contact record.
• FND_PROFILE_OPTION_VALUES — Profile option lookups that govern package behaviour.
• DBMS_SQL, DUAL, PLITBLM — Utility references: dynamic SQL execution (used with the partial where clause and bind array for updated contact points), a dual row source, and the PL/SQL integer table type used for the bind array.

Usage Notes

CS_SRCONTACT_PKG is invoked internally by the Service Request API stack rather than directly by end users. It is typically triggered when a Service Request is created or updated through the Service Requests form, the Service Request API, or via concurrent program processing that manipulates SR contacts. Custom code should not call these procedures directly where a public SR API is available; instead, the supported SR API surface should be used, and this package should be treated as an internal implementation detail. Because the package performs duplicate checking based on contact type, party ID, contact point type, contact point ID, party role code, and overlapping date ranges, deploying customisations that bypass it may allow duplicate SR contact points to be created.