Search Results bic_party_summ




Overview
Explore in AI Chat

Overview

BIC_PARTY_SUMM is a table owned by the BIC schema (Customer Intelligence), classified in the ETRM metadata as part of an obsolete module in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to transpose the rows of the underlying Customer Summary table into columns, producing a flattened, denormalized structure for matrix-style reporting against org-striped measures. In effect, it pre-aggregates customer-level metrics across a reporting period and a business unit, so that downstream reports and analytics can retrieve a wide row of measures for a single party instead of pivoting a narrow result set at query time.

Following the heuristic Data Vault classification mined from the foreign-key structure, this table is satellite-leaning. That is a modeling suggestion rather than a documented designation: the table behaves as a descriptive satellite keyed by a business key (party and period), carrying measured attributes rather than defining a hub or resolving a many-to-many link. It does not act as a party master; the party identity itself is owned elsewhere and referenced here.

Key Information Stored

The table contains 90 documented columns, of which a representative subset carries the analytical payload. The business key is defined by the unique index BIC_PARTY_SUMM_U1 across (PERIOD_START_DATE, PARTY_ID, ORG_ID); there is no separate surrogate primary key documented, so this composite key identifies a row. PARTY_ID is the foreign key to HZ_PARTIES, ORG_ID identifies the operating unit or organization stripe, and PERIOD_START_DATE fixes the reporting period.

The most significant measure columns include:

Standard WHO columns and concurrency fields are also present (LAST_UPDATE_DATE, CREATION_DATE, LAST_UPDATED_BY, CREATED_BY, LAST_UPDATE_LOGIN), together with SECURITY_GROUP_ID, which references FND_SECURITY_GROUPS and supports multi-tenant data segregation, and request-tracking columns (REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE) that identify the concurrent program that populated each row.

Common Use Cases and Queries

Because the table is period-striped, the typical access pattern filters on a party, a date range, and an organization. A representative query retrieving a customer scorecard follows this shape:

  • SELECT PERIOD_START_DATE, ORG_ID, SALES, ORDER_AMT, CLOSED_SRS, ONTIME_SHIP_PCT FROM BIC.BIC_PARTY_SUMM WHERE PARTY_ID = :p_party_id AND PERIOD_START_DATE BETWEEN :p_from AND :p_to ORDER BY PERIOD_START_DATE;
  • Segment-level trending: aggregate SALES, PROFITABILITY, and RETURNS by PERIOD_START_DATE for a MARKET_SEGMENT_ID to produce period-over-period performance reports.
  • Supplier or customer scorecards: combine the SF_ prefixed survey scores (SF_BILLING, SF_CONTRACT, SF_QUALITY, SF_SERVICE, SF_SHIPMENT) with LOYALTY and SATISFACTION for executive dashboards.
  • Operational service reporting: rank parties by AVG_SR_RESPONSE_TIME, AVG_SR_RESL_TIME, or PERCT_CALL_REWORK within an ORG_ID to identify problem accounts.

All queries must respect SECURITY_GROUP_ID to avoid cross-organization leakage in a multi-org deployment.

Related Objects

  • HZ_PARTIES — joined on BIC_PARTY_SUMM.PARTY_ID = HZ_PARTIES.PARTY_ID; supplies party name, number, and classification attributes.
  • FND_SECURITY_GROUPS — joined on BIC_PARTY_SUMM.SECURITY_GROUP_ID; enforces organization-level data access.
  • Customer Summary source table (BIC schema) — the upstream table whose rows are transposed into this flattened structure.
  • Concurrent program and request tables (FND_CONCURRENT_REQUESTS) — related through REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID to trace population runs.
  • FND_ORG assignments / HR operating unit definitions — contextual reference for ORG_ID striping in multi-org reporting.

Given the obsolete status of the BIC module, these relationships are best treated as historical dependencies; where equivalent functionality now resides in Oracle Customer Intelligence successors or custom data marts, the join semantics to HZ_PARTIES and FND_SECURITY_GROUPS remain valid for migration analysis.