Results for “restrict_reason”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

JTF_CONTACT_RESTRICTIONS_V is a reporting and integration view in the APPS schema of Oracle E-Business Suite, owned by the CRM Foundation (JTF) product. It exposes the duration and reason for which a contact type is restricted, presenting contact-level "do not" preferences in a denormalized form suited to inquiry and downstream processing. The view is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2 and is defined as a read-only projection over the contact preference data model.

The view filters the underlying preference table so that only records with a preference code of 'DO_NOT' are returned, and it excludes rows whose contact level table equals 'HZ_CONTACT_POINTS'. The result is a focused list of contact restrictions, each carrying a start date, an end date, a reason code, and audit columns. Its principal role is to give applications, reports, and interfaces a stable, semantically named source of restriction information without requiring consumers to understand the underlying preference-code encoding.

Underlying Base Objects

The view is defined exclusively over HZ_CONTACT_PREFERENCES, referenced through the APPS synonym documented in the ETRM metadata. The defining query aliases that table as A and selects all columns through direct projection, with column renaming applied to align the preference model with restriction terminology. No joins, unions, or additional tables participate in the definition, so the row population of the view is determined entirely by the two predicates applied in the WHERE clause: A.PREFERENCE_CODE = 'DO_NOT' and A.CONTACT_LEVEL_TABLE <> 'HZ_CONTACT_POINTS'.

Because the view is a single-table projection with filtering, it is inherently non-updatable in the ETRM-documented form; inserts, updates, and deletes must be directed to HZ_CONTACT_PREFERENCES. The WH_UPDATE_DATE column is populated with TO_DATE(NULL), indicating it is a placeholder for warehouse or incremental-extract purposes rather than a stored attribute.

Key Columns

• CONTACT_RESTRICTION_ID — Renamed from CONTACT_PREFERENCE_ID; the unique identifier of the restriction record.
• CONTACT_TYPE — The contact type to which the restriction applies.
• RESTRICT_START_DATE — Start of the restriction interval (from PREFERENCE_START_DATE).
• RESTRICT_END_DATE — End of the restriction interval (from PREFERENCE_END_DATE).
• RESTRICT_REASON — Reason code explaining the restriction (from REASON_CODE).
• SUBJECT_TABLE — The contact level table identifying the entity type owning the restriction; sourced from CONTACT_LEVEL_TABLE and central to the subject_table search term.
• SUBJECT_ID — The primary key of the subject entity within SUBJECT_TABLE (from CONTACT_LEVEL_TABLE_ID).
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE, LAST_UPDATED_BY, and the concurrent program columns REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE.

Common Use Cases and Queries

Typical uses include enforcing do-not-contact policies, auditing active restrictions, and extracting restriction data into data warehouses. A basic listing of active restrictions follows:

SELECT CONTACT_RESTRICTION_ID, CONTACT_TYPE, RESTRICT_START_DATE, RESTRICT_END_DATE, RESTRICT_REASON, SUBJECT_TABLE, SUBJECT_ID FROM APPS.JTF_CONTACT_RESTRICTIONS_V WHERE SYSDATE BETWEEN RESTRICT_START_DATE AND NVL(RESTRICT_END_DATE, SYSDATE + 1);

To inspect the restriction subjects by entity type:

SELECT SUBJECT_TABLE, COUNT(*) FROM APPS.JTF_CONTACT_RESTRICTIONS_V GROUP BY SUBJECT_TABLE;

Because SUBJECT_TABLE acts as a polymorphic discriminator, applications join it conditionally to the appropriate entity table identified by SUBJECT_ID. Incremental extraction can use LAST_UPDATE_DATE, while REQUEST_ID and PROGRAM_ID support lineage tracking to the concurrent program that created or modified each restriction.