Search Results hz_contact_preference_v2pub




Overview
Explore in AI Chat

Overview

The APPS.HZ_CONTACT_PREFERENCE_VALIDATE package is a validation utility within the Oracle E-Business Suite Trading Community Architecture (TCA) data model. Its business purpose is to enforce business rules associated with contact preferences — the customer-configurable settings that govern whether and how a party may be contacted through channels such as e-mail, telephone, fax, or direct mail. In Oracle EBS 12.1.1 and 12.2.2, contact preference records are maintained in the HZ_CONTACT_PREFERENCES table, and this package provides the centralized validation logic that protects the integrity of those records before they are committed to the database.

This package is closely coupled with HZ_CONTACT_PREFERENCE_V2PUB, the public TCA API used to create and update contact preference records. Users searching for the phrase "hz_contact_preference_v2pub" are typically working with that public API, and this validate package is one of its direct dependencies. The dependency metadata confirms a bidirectional relationship: HZ_CONTACT_PREFERENCE_VALIDATE references HZ_CONTACT_PREFERENCE_V2PUB, and HZ_CONTACT_PREFERENCE_V2PUB in turn references this validate package. The package is classified under ETRM as an API of type OTHER, reflecting its role as an internal helper rather than a standalone public interface.

Key Procedures and Functions

The ETRM metadata documents a single program unit within this package:

  • VALIDATE_CONTACT_PREFERENCE — The sole documented procedure. Its purpose is to validate a contact preference record against TCA business rules before the record is persisted. As an internal validation routine, it is invoked by the parent public API (HZ_CONTACT_PREFERENCE_V2PUB) rather than being called directly by external consumers. Consistent with ETRM documentation practice, parameter lists are not enumerated here; the procedure operates on the contact preference payload passed by the calling API and raises validation errors when the supplied data violates configured constraints, such as invalid lookup values or mismatched party, site, or contact point references.

Tables Accessed

The package reads from several reference and transactional tables through APPS synonyms. These accesses support both look-up validation and referential-integrity checks:

  • HZ_CONTACT_PREFERENCES — The primary transaction table holding contact preference records; used to validate the target row and detect conflicting or duplicate settings.
  • HZ_CONTACT_POINTS — Provides the contact point (telephone, e-mail, and similar) that a preference applies to; the preference must reference a valid contact point.
  • HZ_PARTIES and HZ_PARTY_SITES — Confirm that the party and party site associated with the preference exist and are consistent, enforcing TCA party-model integrity.
  • FND_LOOKUP_VALUES — Supplies the valid lookup codes used to validate enumerated preference attributes.
  • AMS_SOURCE_CODES, AS_INTEREST_CODES_B, and AS_INTEREST_TYPES_B — Marketing-related reference tables used to validate interest code and interest type values associated with the preference.

Collectively, these tables indicate that validation covers party identification, contact point validity, preference type enumeration, and marketing interest attributes.

Usage Notes

This package is not intended as a public API. It is invoked internally by HZ_CONTACT_PREFERENCE_V2PUB during create, update, or delete operations on contact preferences, and by the Oracle Forms-based customer and contact maintenance screens that call that API. Custom integrations that maintain contact preferences programmatically should route their inserts and updates through HZ_CONTACT_PREFERENCE_V2PUB so that this validation logic executes automatically; calling the validate package directly bypasses supported API semantics and is not recommended. The package is reported as VALID in both 12.1.1 and 12.2.2, and its use of SYS.STANDARD reflects standard PL/SQL built-in dependencies only. Because it is referenced by one other package, changes to its interface should be assessed against the calling public API before any modification.