Search Results decision_maker_flag

Overview

ICX_RA_CONTACTS_V is a reporting and integration view in Oracle E-Business Suite, associated with the ICX (Oracle iProcurement) product family. Its documented description is "Customer Contacts View." The object is a pass-through view defined over the Oracle Receivables base table RA_CONTACTS, exposing customer contact records in a form suitable for consumption by iProcurement and other EBS modules that must resolve buyer or requester contact information during requisition entry and order processing.

Because the view is a simple projection, it carries no filtering, join, or aggregation logic of its own; the row set it returns is identical to that of RA_CONTACTS, with the same column list in the same order. The ETRM metadata records "Not implemented in this database" for the implementation/DBA data, which is a common annotation for views that are shipped as part of a product's schema definition but are not created in every environment. The 12.2.2 metadata lists the owner as blank and records no referenced base objects, despite the embedded view text clearly selecting from RA_CONTACTS. Practitioners should therefore treat the view text, not the documented reference list, as authoritative.

Underlying Base Objects

The single documented source object is RA_CONTACTS, the Oracle Receivables table that stores customer contact persons. The view selects every column from that table in an explicit, ordered list rather than using a wildcard, which means the column set is fixed at the time the view definition was compiled. Key attributes trace back to RA_CONTACTS: CONTACT_ID, CUSTOMER_ID, STATUS, LAST_NAME, FIRST_NAME, TITLE, JOB_TITLE, ADDRESS_ID, EMAIL_ADDRESS, and the WHO-column audit set (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN).

No joins to RA_CUSTOMERS, HZ_PARTIES, or any address table are documented within the view, so any customer name or location information must be obtained by joining outside the view. This is an important design consideration when building reports: the view delivers contacts, not the customer hierarchy.

Key Columns

• CONTACT_ID — Primary identifier of the contact record; the join key back to RA_CONTACTS and to contact-related child objects.
• CUSTOMER_ID — Identifies the customer account to which the contact belongs.
• STATUS — Lifecycle status of the contact, typically distinguishing active from inactive records.
• LAST_NAME, FIRST_NAME, SUFFIX, TITLE, JOB_TITLE — Name and professional designation data used when displaying or addressing the contact.
• EMAIL_ADDRESS — Contact e-mail, relevant for notification workflows in iProcurement.
• ADDRESS_ID, MAILING_ADDRESS_ID, MAIL_STOP — Address references and internal mail stop information.
• DECISION_MAKER_FLAG — Indicates whether the contact has purchasing decision authority; significant for sourcing and approval logic.
• REFERENCE_USE_FLAG — The column that prompted the search. It indicates whether the contact may be used as a reference, supporting customer-reference checks and reference-usage reporting.
• DO_NOT_MAIL_FLAG — Suppresses postal mailing for the contact, relevant to correspondence reporting.
• CONTACT_KEY, CONTACT_NUMBER, PRIMARY_ROLE, RANK, MANAGED_BY, NATIVE_LANGUAGE, ORIG_SYSTEM_REFERENCE — Integration and hierarchy attributes, including the originating system key for records imported from external sources.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE25 — The standard EBS descriptive flexfield and attribute segments, available for customer-specific extensions.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program audit columns recording the process that last touched the record.

Common Use Cases and Queries

Typical uses include listing active contacts for a customer, identifying decision makers, and reporting on reference-eligible contacts for a given account. Because REFERENCE_USE_FLAG is exposed without translation, it is normally reported alongside a lookup or decoded manually.

Example 1 — active contacts for a customer:

SELECT contact_id, last_name, first_name, email_address FROM icx_ra_contacts_v WHERE customer_id = :p_customer_id AND status = 'A';

Example 2 — reference-eligible contacts:

SELECT cust.customer_name, c.last_name, c.first_name, c.reference_use_flag FROM icx_ra_contacts_v c, ra_customers cust WHERE c.customer_id = cust.customer_id AND c.reference_use_flag = 'Y';

Example 3 — decision makers with updated audit information:

SELECT contact_id, last_name, job_title, decision_maker_flag, last_update_date, last_updated_by FROM icx_ra_contacts_v WHERE customer_id = :p_customer_id AND decision_maker_flag = 'Y' ORDER BY last_name;

Queries should always join to RA_CUSTOMERS or the Trading Community Architecture tables when customer names are required, since the view itself provides no customer descriptive data.