Search Results bic_party_status_summ




Overview
Explore in AI Chat

Overview

BIC.BIC_PARTY_STATUS_SUMM is a table within the Oracle E-Business Suite BIC – Customer Intelligence product. The BIC module is flagged as Obsolete in the ETRM 12.2.2 repository, meaning that while the object remains physically VALID in the schema, it is no longer part of the actively supported product footprint and should generally be treated as a legacy or historical construct.

Functionally, the table is a flattened, denormalized summary of party-level status measures. As the ETRM description states, rows from an underlying "Party Summary" table are transposed into columns to support matrix-style reporting — specifically for non-org striped measures. In other words, rather than representing each measure as a row, the table pivots those measures into discrete columns, enabling direct matrix and cross-tab reporting against a single party record per period.

Applying a heuristic Data Vault classification based on the documented foreign-key structure, the object is satellite-leaning. Its grain is keyed by a business identifier (party) combined with a period, and it carries descriptive, time-varying measures — the profile of a satellite attached to a party hub rather than a hub or link in its own right. This is offered as a modeling suggestion only; the physical table is not implemented as a formal Data Vault artifact.

Key Information Stored

The table exposes 17 documented columns. The most operationally significant are:

The metadata does not document an explicit surrogate primary key or unique index on this table, so no formal surrogate-vs-business-key distinction can be asserted from ETRM alone. Based on the structure, PARTY_ID combined with PERIOD_START_DATE (and SECURITY_GROUP_ID where org-striping applies) is the most plausible composite business key.

Common Use Cases and Queries

Because the table is pre-pivoted, its primary use is direct matrix reporting on customer lifecycle measures by party and period. A typical retrieval pattern filters to a reporting window and security context:

  • Lifecycle trend analysis — tracking ACQUISITION, ACTIVATION, and RETENTION movements for a party across successive PERIOD_START_DATE values.
  • Segmented reporting — aggregating measures by MARKET_SEGMENT_ID to compare performance across customer segments.
  • Refresh auditing — reviewing PROGRAM_ID, REQUEST_ID, and PROGRAM_UPDATE_DATE to determine the last population run and its source program.

A representative query joining to the party master would be:

SELECT p.party_name, s.period_start_date, s.acquisition, s.activation, s.retention, s.life_cycle
FROM bic.bic_party_status_summ s, hz_parties p
WHERE s.party_id = p.party_id
AND s.period_start_date BETWEEN :from_date AND :to_date;
ORDER BY p.party_name, s.period_start_date;

All access should respect SECURITY_GROUP_ID filtering consistent with the caller's operating unit and security profile.

Related Objects

The documented foreign keys and dependencies define the object's immediate lineage:

  • HZ_PARTIES — joined via BIC_PARTY_STATUS_SUMM.PARTY_ID; the party master providing names and party classifications.
  • FND_SECURITY_GROUPS — joined via SECURITY_GROUP_ID; governs data-security and multi-org partitioning.
  • FND_CONCURRENT_REQUESTS — resolves REQUEST_ID to the concurrent job that populated the summary rows.
  • FND_PROGRAM / FND_APPLICATION — resolve PROGRAM_ID and PROGRAM_APPLICATION_ID for refresh lineage.
  • FND_USER — resolves CREATED_BY and LAST_UPDATED_BY for audit attribution.

Given the module's obsolete status, architects planning migrations or custom reporting should confirm whether this table is still populated by an active concurrent program before building dependencies upon it.