Search Results preference_end_date

Overview

HZ_CONTACT_RESTRICTIONS is a compatibility view in the Oracle E-Business Suite Receivables (AR) module that exposes contact-level "do not contact" preferences maintained in the Oracle Trading Community Architecture (TCA) data model. The view presents a normalized, reporting-friendly projection of records that would otherwise require filtering and column aliasing against the underlying preferences table. Its name and column set correspond to the contact restriction concept used by earlier releases and by downstream features that need to determine whether a party, account, or contact site has requested suppression of outbound communication.

The view is defined as a filtered SELECT over HZ_CONTACT_PREFERENCES, restricting rows to those where PREFERENCE_CODE equals the literal 'DO_NOT' and excluding records whose CONTACT_LEVEL_TABLE is 'HZ_CONTACT_POINTS'. This means the view reports restrictions expressed at the party, account, or contact level, but excludes restrictions scoped specifically to a contact point such as a phone number or e-mail address. The user query "do_not" maps directly to this filter, which is the defining characteristic of the object.

Underlying Base Objects

The only documented base object is HZ_CONTACT_PREFERENCES, a TCA table that stores contact preference and restriction declarations across multiple levels of the customer model. The ETRM metadata records no additional referenced objects, indicating the view is a single-table projection with column renaming rather than a join.

• CONTACT_PREFERENCE_ID is aliased to CONTACT_RESTRICTION_ID.
• CONTACT_LEVEL_TABLE is aliased to SUBJECT_TABLE, and CONTACT_LEVEL_TABLE_ID to SUBJECT_ID.
• PREFERENCE_START_DATE and PREFERENCE_END_DATE become RESTRICT_START_DATE and RESTRICT_END_DATE.
• REASON_CODE becomes RESTRICT_REASON.
• WH_UPDATE_DATE is materialized as TO_DATE(NULL), a placeholder column retained for warehouse-style extraction compatibility.

According to the supplied metadata the view is not implemented in the reference database and has no documented owner; availability therefore depends on site-specific installation and patch level across 12.1.1 and 12.2.2.

Key Columns

• CONTACT_RESTRICTION_ID — surrogate identifier inherited from the source preference record; unique per restriction row.
• SUBJECT_TABLE / SUBJECT_ID — the entity to which the restriction applies (for example party, account, or contact level) and its primary key. These drive how the restriction is resolved to a customer, site, or person.
• CONTACT_TYPE — the contact channel or medium governed by the restriction, such as phone, e-mail, or mail.
• RESTRICT_START_DATE / RESTRICT_END_DATE — validity window of the do-not-contact instruction; a null end date generally denotes an open-ended restriction.
• RESTRICT_REASON — coded reason supplied when the preference was captured.
• STATUS — lifecycle indicator for the preference record.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE support traceability and concurrent program lineage.

Common Use Cases and Queries

Typical scenarios include suppression list generation for campaigns, compliance reporting on customer contact preferences, and integration extracts that push do-not-contact flags to external marketing or telephony systems. A representative query follows.

SELECT CONTACT_RESTRICTION_ID, SUBJECT_TABLE, SUBJECT_ID, CONTACT_TYPE, RESTRICT_START_DATE, RESTRICT_END_DATE, RESTRICT_REASON, STATUS FROM HZ_CONTACT_RESTRICTIONS WHERE STATUS = 'A' AND (RESTRICT_END_DATE IS NULL OR RESTRICT_END_DATE > SYSDATE);

Because contact-point-level restrictions are deliberately excluded, implementations requiring suppression at the phone or e-mail level must query HZ_CONTACT_PREFERENCES directly with the appropriate CONTACT_LEVEL_TABLE filter. Always validate object existence and row counts in each environment, since the metadata indicates the view is not universally implemented.