Search Results bic_contacts_v

Overview

BIC_CONTACTS_V is a reporting view historically shipped with the Oracle E-Business Suite Customer Intelligence (BIC) module, a product line that has since been discontinued and is not implemented in current 12.1.1 or 12.2.2 installations. The view consolidates person-level contact information into a single, denormalized record set, exposing a party identifier, a formatted contact name, a formatted telephone number, an e-mail address, and a primary address. Its intended role was to serve as a convenient foundation for customer intelligence analytics, list generation, and outbound marketing extracts, sparing report authors from repeatedly joining the TCA (Trading Community Architecture) contact point and party tables.

Because the object is marked obsolete and is documented as not implemented, references to it are most often encountered when migrating or reviewing legacy customizations. Any dependency on BIC_CONTACTS_V in a 12.1.1 or 12.2.2 environment must be treated as a broken reference and re-pointed to supported TCA objects.

Underlying Base Objects

The view text defines its sources through inline joins rather than a documented dependency list, and no referenced base objects are recorded in the ETRM metadata. The participating objects are:

• HZ_PARTIES (PA) — the driving table, restricted to records where PARTY_TYPE is 'PERSON'.
• HZ_PARTY_SITES (PS) — outer-joined to HZ_PARTIES and filtered by IDENTIFYING_ADDRESS_FLAG = 'Y' to select the party's primary site.
• BIC_ADDRESS_V (AD) — an outer-joined companion view supplying the formatted primary address, itself keyed by LOCATION_ID.
• HZ_CONTACT_POINTS (CPP) — outer-joined alias supplying telephone data where CONTACT_POINT_TYPE = 'PHONE'.
• HZ_CONTACT_POINTS (CPE) — a second, independently outer-joined instance of the same table supplying e-mail data where CONTACT_POINT_TYPE = 'EMAIL'.

Both contact point joins are constrained by OWNER_TABLE_NAME = 'HZ_PARTIES' and OWNER_TABLE_ID equal to the party identifier. All joins to sites, addresses, and contact points use the Oracle outer-join syntax, so a party with no phone, e-mail, or identifying address still appears with null values in the affected columns. The view is declared WITH READ ONLY.

Key Columns

• PARTY_ID — the HZ_PARTIES.PARTY_ID of the person; the view's effective primary key and the join key back to TCA.
• CONTACT_NAME — a concatenation of PERSON_LAST_NAME, a space, and PERSON_FIRST_NAME, yielding a single "last first" display name.
• CONTACT_PHONE — formed as PHONE_AREA_CODE concatenated with a hyphen and PHONE_NUMBER. This is the column most directly associated with the search term "contact_phone" and represents only those contact points of type PHONE owned by the party.
• CONTACT_EMAIL — EMAIL_ADDRESS from the e-mail-typed contact point record.
• PRIMARY_ADDRESS — the formatted address sourced from BIC_ADDRESS_V for the party's identifying site.

Common Use Cases and Queries

Typical legacy usage involved producing contact lists for campaigns or feeding downstream analytics with minimal join effort, as shown below.

SELECT party_id, contact_name, contact_phone, contact_email, primary_address FROM bic_contacts_v WHERE contact_phone IS NOT NULL ORDER BY contact_name;

A targeted lookup by name or e-mail followed the same pattern:

SELECT contact_name, contact_phone FROM bic_contacts_v WHERE contact_email = :email_address;

In a supported 12.1.1 or 12.2.2 environment, equivalent output must be rebuilt directly against HZ_PARTIES and HZ_CONTACT_POINTS, filtering on CONTACT_POINT_TYPE and OWNER_TABLE_NAME and applying contact point purpose or primary-flag logic to avoid row multiplication where multiple phone records exist. Attempting to query BIC_CONTACTS_V will fail with an invalid-identifier error, since the object is not created in the database.