Search Results acquired_date




Overview
Explore in AI Chat

Overview

BIC_PARTY_LIST_V is a reporting view historically shipped within the Oracle E-Business Suite Customer Intelligence (BIC) product family. Customer Intelligence was an analytical layer that sat above the TCA (Trading Community Architecture) registry, exposing flattened, denormalized party data for downstream reporting and integration. In the 12.1.1 and 12.2.2 releases the BIC product is classified as obsolete, and the view is documented as not implemented in the base database; the ETRM metadata nonetheless preserves its definition for reference and upgrade-impact analysis.

The view consolidates two populations of trading community entities into a single row set: standalone parties (organizations and persons) and party relationships (for example, contact-to-organization or organizational hierarchy links). The result is a uniform party directory with a consistent column projection suitable for customer intelligence extracts, segmentation feeds, and third-party analytics ingestion. Because the view is defined with WITH READ ONLY, it is strictly a query surface and cannot be used as a DML target.

Underlying Base Objects

The view is defined over the TCA registry and the Oracle Marketing (AMS) segmentation tables. The documented base objects are:

The view is a UNION of two SELECTs. The first selects all parties whose PARTY_TYPE is not 'PARTY_RELATIONSHIP', with NULL placeholders for the relationship columns. The second selects relationship rows, excluding any relationship type present in BIC_RELATIONSHIP_TYPES, and joins the lookup table to translate the relationship code into a display meaning.

Key Columns

  • PARTY_ID — Primary identifier of the party in HZ_PARTIES.
  • CUSTOMER_NAME — Party name, mapped from HZ_PARTIES.PARTY_NAME.
  • RELATIONSHIP — Decoded relationship meaning from AR_LOOKUPS; NULL for the standalone-party branch.
  • RELATED_PARTY — Name of the object party in a relationship; NULL for standalone parties.
  • ACQUIRED_DATE — Mapped from HZ_PARTIES.CREATION_DATE. This is the column that answers the "acquired_date" search term: the view treats the party record's creation date as the acquisition date.
  • CUSTOMER_CATEGORY_FK — CATEGORY_CODE from HZ_PARTIES, identifying the party category.
  • MARKET_SEGMENT_FK — MARKET_SEGMENT_ID from AMS_PARTY_MARKET_SEGMENTS.
  • COUNTRY / STATE / CITY — Address components from HZ_PARTIES.
  • ADDRESS — A concatenated multi-line address built via DECODE, combining ADDRESS1, CITY, STATE, POSTAL_CODE, COUNTY, and COUNTRY with CHR(10) line breaks; returns NULL when ADDRESS1 is NULL.

Common Use Cases and Queries

Because the view flattens party, relationship, and segmentation data, it supports customer directory extracts, segmentation analysis, and relationship mapping without the caller needing to reconstruct joins. A typical query to retrieve parties acquired within a period is:

  • SELECT party_id, customer_name, acquired_date FROM bic_party_list_v WHERE acquired_date >= :from_date;
  • SELECT customer_name, relationship, related_party FROM bic_party_list_v WHERE relationship IS NOT NULL;
  • SELECT customer_name, market_segment_fk, address FROM bic_party_list_v WHERE market_segment_fk = :segment_id;

Note that since BIC is obsolete and the view is not implemented in the current database, equivalent reporting in 12.1.1/12.2.2 should generally be built directly against HZ_PARTIES, HZ_PARTY_RELATIONSHIPS, and AMS_PARTY_MARKET_SEGMENTS. The ACQUIRED_DATE semantics, however, remain useful: HZ_PARTIES.CREATION_DATE is the standard proxy for party acquisition date in TCA-based reporting.