Search Results qa_bis_results




Overview
Explore in AI Chat

Overview

QA_BIS_RESULTS is a summary table owned by the QA (Quality) schema in Oracle E-Business Suite, described in the ETRM documentation as a "BIS Summary Table." BIS refers to Business Intelligence System / Oracle Business Intelligence reporting structures used within the Quality module. The table functions as a denormalized reporting and aggregation object that pre-joins quality plan, collection, item, lot, and defect dimensions into a single wide structure, enabling fast query performance for quality results analysis without traversing the full transactional model in the QA schema.

From a modeling perspective, the metadata classifies QA_BIS_RESULTS heuristically as standalone, with no foreign key dependencies mined from the FK structure. This suggests it behaves less like a normalized hub or link and more like a satellite-style summary or materialized reporting table whose grain is defined by the OCCURRENCE column rather than by a business transaction key. The absence of foreign keys reinforces its role as a read-oriented, possibly refreshed, snapshot structure rather than a transactional parent.

Key Information Stored

The table contains 25 documented columns. Its surrogate/primary key is QA_BIS_RESULTS_PK, defined on the OCCURRENCE column. A unique index, QA_BIS_RESULTS_U1, is also defined on OCCURRENCE, making OCCURRENCE both the primary key and the business-key candidate for this structure.

Common Use Cases and Queries

Because QA_BIS_RESULTS is a summary table, its principal use is BI reporting and quality analytics: defect rate by item, defect trends by organization, plan-type effectiveness, and lot-level defect concentration. Typical queries filter by organization, plan, or date range and aggregate QUANTITY_DEFECTIVE.

  • Defects by item and organization: SELECT ITEM, ORGANIZATION_NAME, SUM(QUANTITY_DEFECTIVE) FROM QA.QA_BIS_RESULTS GROUP BY ITEM, ORGANIZATION_NAME;
  • Defect trend by plan type: group by PLAN_TYPE_MEANING and QA_CREATION_DATE to trend plan effectiveness.
  • Lot-level analysis: join LOT_NUMBER back to inventory lot tables using ITEM_ID and LOT_NUMBER.
  • Refresh audit: inspect REQUEST_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE to confirm when the summary was last rebuilt by its concurrent program.
  • Defect code frequency: SELECT DEFECT_CODE, COUNT(*), SUM(QUANTITY_DEFECTIVE) FROM QA.QA_BIS_RESULTS GROUP BY DEFECT_CODE;

Related Objects

The metadata documents no foreign keys, so relationships to other objects are logical rather than enforced. The most significant related objects are: