Search Results hz_contact_restrictions




Overview
Explore in AI Chat

Overview

The HZ_CONTACT_RESTRICTIONS table is a core data object within the Oracle E-Business Suite (EBS) Trading Community Architecture (TCA) model, specifically under the Receivables (AR) product module. It serves a critical compliance and customer relationship management function by storing explicit restrictions on how and when an organization may contact its parties (customers, suppliers, etc.) or their specific locations. This table enables businesses to respect legal mandates, such as "Do Not Call" lists, and honor individual privacy preferences, thereby mitigating risk and fostering responsible communication practices. Its role is integral to maintaining a centralized, auditable record of contact prohibitions across all EBS applications that interact with party data.

Key Information Stored

The table's primary purpose is to define the restriction's scope, type, and validity. While the provided metadata does not list specific columns, based on its documented purpose and relationships, the table typically contains key attributes. A surrogate primary key, CONTACT_RESTRICTION_ID, uniquely identifies each restriction record. The SUBJECT_ID column, as indicated by the foreign key relationships, stores the identifier for the entity to which the restriction applies—either a Party (from HZ_PARTIES) or a Party Site (from HZ_PARTY_SITES). Other common columns include fields to specify the RESTRICTION_TYPE (e.g., 'DO_NOT_CALL', 'DO_NOT_EMAIL'), an effective start and end date to manage the restriction's active period, and the context or source of the restriction. The structure allows for granular control over communication channels for entire parties or specific addresses.

Common Use Cases and Queries

A primary use case is screening contact lists before executing marketing campaigns or customer outreach via phone or email. Applications can query this table to filter out parties with active restrictions. For reporting, organizations may run audits to list all parties with specific contact bans. Common SQL patterns involve joining to party information tables. For example, to find all active 'DO_NOT_CALL' restrictions for customers, a query might join HZ_CONTACT_RESTRICTIONS to HZ_PARTIES and HZ_CUST_ACCOUNTS. Another critical operational use is within the user interface of the Trading Community Manager, where restrictions are created and maintained, and these interfaces ultimately perform DML operations (INSERT, UPDATE) on this underlying table.

Related Objects

The table maintains defined relationships with other central TCA entities, as per the provided metadata. Its primary key is enforced by the HZ_CONTACT_RESTRICTIONS_PK constraint on the CONTACT_RESTRICTION_ID column. It references two key tables via foreign keys on the SUBJECT_ID column:

  • HZ_PARTIES: This links a restriction to a general party record (e.g., an individual or organization).
  • HZ_PARTY_SITES: This links a restriction to a specific address or location of a party, allowing for more granular control.

This dual foreign key relationship indicates that the SUBJECT_ID can be interpreted differently based on context, requiring application logic or a separate column (often named SUBJECT_TABLE_NAME or SUBJECT_TYPE) to disambiguate whether it points to a Party or a Party Site. The table is also foundational for any APIs or views that expose party restriction data for consumption by other EBS modules like TeleSales, Marketing, and Service.