Search Results bic_new_party_list_v

Overview

BIC_NEW_PARTY_LIST_V is a reporting view historically shipped with the Oracle E-Business Suite Customer Intelligence (BIC) module. Customer Intelligence was a CRM analytics product that provided dashboards and extracts for customer profiling, segmentation, and loyalty analysis. In ETRM 12.1.1 and 12.2.2 the module is classified as obsolete, and the view itself is documented as not implemented in the reference database. The view is therefore best understood as a legacy BI interface object rather than a supported runtime component.

The view presents a denormalized list of trading parties (customers) joined to a set of analytical attributes held in the BIC party transaction data table. Its purpose was to expose a single, flat row per party suitable for loading into a data warehouse or a Customer Intelligence dashboard, avoiding the caller having to join the TCA party registry to the BIC analytics table directly. The user search term customer_category_fk corresponds to the aliased column CUSTOMER_CATEGORY_FK, which is one of the principal segmentation attributes the view exposes.

Underlying Base Objects

The view text references two objects:

• HZ_PARTIES — aliased as A, the TCA (Trading Community Architecture) master registry of parties. It supplies PARTY_ID, PARTY_NAME (projected as CUSTOMER_NAME), COUNTRY, STATE, and CITY.
• BIC_PARTY_TXN_DATA — aliased as T, a Customer Intelligence staging/analytics table holding derived customer attributes such as category, market segment, acquisition date, satisfaction, and loyalty.

The join is expressed as A.PARTY_ID = T.PARTY_ID(+). The outer-join symbol on the BIC table means every party in HZ_PARTIES is retained even where no analytical row exists, with the segmentation columns returning NULL. The DISTINCT keyword is applied to the full projection, indicating that the underlying join is expected to be non-unique and requires deduplication. The ETRM metadata documents no formal foreign-key constraints or referenced base objects; relationships are inferred solely from the view text.

Key Columns

• PARTY_ID — surrogate primary key of the party in HZ_PARTIES; the anchor for all downstream joins.
• CUSTOMER_NAME — the party name, aliased from A.PARTY_NAME for reporting readability.
• CUSTOMER_CATEGORY_FK — mapped from T.CATEGORY_CODE; the customer category classification. This is the column the searcher for customer_category_fk is targeting, and it functions as a foreign-key-style reference to the category definition rather than a resolved description.
• MARKET_SEGMENT_FK — mapped from T.MARKET_SEGMENT_ID; the market segment assignment for the party.
• ACQUIRED_DATE — date the customer relationship was acquired.
• NO_OF_RELATED_PARTIES — count of related parties for the customer.
• SATISFACTION and LOYALTY — derived analytical scores for the customer.
• COUNTRY, STATE, CITY — geographic attributes sourced from the party record.

Common Use Cases and Queries

Because the view is obsolete and not implemented, it should not be referenced in new development. Where it exists in a legacy instance, typical usage was to drive segmentation or loyalty extracts. A representative query filtering on the category attribute would resemble:

• SELECT party_id, customer_name, customer_category_fk, market_segment_fk FROM bic_new_party_list_v WHERE customer_category_fk = :p_category;
• SELECT customer_category_fk, COUNT(*) FROM bic_new_party_list_v GROUP BY customer_category_fk;
• SELECT party_id, customer_name, acquired_date FROM bic_new_party_list_v WHERE acquired_date >= :p_from_date;

In current 12.1.1 and 12.2.2 environments, equivalent data should be sourced from supported TCA and Customer Intelligence replacement objects, since this view is retained only for historical or migration reference.