Search Results g_varchar2

Overview

APPS.ARP_CONT_PKG is a server-side PL/SQL package that encapsulates the core data manipulation and validation logic for customer contact records in Oracle Receivables. It operates against the AR_CONTACTS table and its associated contact entities, providing a programmatic interface for creating, updating, and locking contact rows while enforcing Receivables-specific business rules such as uniqueness of contact names within a customer and uniqueness of originating system references.

The package header declares three public constants that are used throughout Oracle EBS as sentinel values to signal "no change" or "system default" states during an update or merge operation. The constant g_varchar2 is defined as varchar2(9) with the literal value '$Sys_Def$'. Two companion constants are also declared: g_number as the value -987123654 and g_date as the date 01-01-4712 BC (formatted 'DD-MM-SYYYY'). Together, these constants allow callers of the package's update and merge routines to pass these distinctive values in place of genuine column values, indicating that the corresponding attribute should not be modified. The user search for "g_varchar2" refers directly to this declared constant within the package specification.

Key Procedures and Functions

• CHECK_UNIQUE_CONTACT_NAME — Validates that the combination of a contact's first name and last name is unique for a given customer. It accepts a row identifier, customer identifier, first name, last name, and an IN OUT warning flag that communicates the validation result back to the caller.
• CHECK_UNIQUE_ORIG_SYSTEM_REF — Verifies that the originating system reference associated with a contact is unique, preventing duplicate records originating from external or legacy systems. It accepts a row identifier and the originating system reference value.
• INSERT_ROW — Inserts a new contact row into AR_CONTACTS. It accepts the full set of contact attributes, including identifiers, audit columns, address reference, contact key, name fields, job title, mail stop, title, twenty-five descriptive flexfield attribute columns, email address, and alternate name fields, and returns generated values for the row identifier, contact identifier, and originating system reference through IN OUT NOCOPY parameters.
• LOCK_ROW — Obtains a row-level lock on a contact record to serialize concurrent updates, ensuring that two sessions cannot modify the same contact simultaneously. It accepts a row identifier and the contact identifier along with key descriptive columns used for optimistic locking.
• UPDATE_ROW — Updates an existing contact record with new attribute values while honoring the package's sentinel constants to determine which columns should remain unchanged.

Tables Accessed

The metadata documents the procedures but does not enumerate table references exercised through APPS synonyms. The primary table manipulated is AR_CONTACTS, which stores customer contact information in Receivables, including names, titles, address references, and descriptive flexfield attributes. The uniqueness validations implicitly query this same table to detect conflicting names and originating system references. Audit and concurrency behavior follows the standard EBS pattern using WHO columns (created_by, creation_date, last_updated_by, last_update_date, last_update_login) supplied as procedure parameters.

Usage Notes

ARP_CONT_PKG is an internal, non-shipped ("noship") package header identified in the source as AROCONTS.pls, version 120.1, dated 2005. It is invoked indirectly by the Receivables Contacts forms and by other Receivables server-side code that performs contact maintenance, rather than being a public documented API intended for customer extension. Because the package is classified as OTHER and reports no downstream package dependencies, custom developers should treat it as a private implementation detail: direct calls are feasible from custom PL/SQL, but this practice is unsupported, and the package may change between releases. When custom code must create or modify contacts, the supported path remains the Receivables open interfaces and public APIs. Any use of the g_varchar2 sentinel value in custom logic should mirror the package's own convention, passing '$Sys_Def$' only where the procedure contract explicitly anticipates an unchanged or default indicator.