Search Results okl_cntr_grp

Overview

APPS.CSI_COUNTER_READINGS_BCV_V is a business-component-style (BCV) database view within the Oracle E-Business Suite CSI (Customer Service Intelligence) schema. It consolidates counter definition data and the associated counter readings into a single denormalized row structure, presenting both the metering header attributes and the transaction-level reading values. In the Oracle ETRM (Enterprise Telemetry and Reporting Model) context, the view serves as a reporting and integration surface for usage-based and metered contract scenarios, where physical counters on equipment, products, or service points accumulate readings that drive billing, allowances, and performance tracking.

The name reflects its lineage: it joins counter reading rows from the CSI_COUNTER_READINGS table with counter definition rows from the CSI_COUNTERS_BC_V view, and enriches the result with lookup meanings and transaction-type decoding. The "_BCV_V" suffix indicates that it is a "BC" (business component) view, meaning it is intended for use by application modules and external interfaces rather than as a persisted data store. Its principal consumers are ETRM reporting, Oracle Service Contracts metering, and custom integrations requiring normalized counter usage data.

Underlying Base Objects

The view is defined over the following documented objects:

• CSI_COUNTERS_BC_V (VIEW) — supplies counter definition attributes such as COUNTER_GROUP_ID, NAME, DESCRIPTION, INITIAL_READING, UOM_CODE, tolerances, TYPE, rollover settings, and active date ranges.
• CSI_COUNTER_READINGS (SYNONYM) — supplies the transaction-level reading rows (COUNTER_ID, VALUE_TIMESTAMP, COUNTER_READING, NET_READING, reset indicators, adjustments).
• CSI_COUNTER_READINGS_PVT (PACKAGE) — provides the PL/SQL functions GET_READING_BEFORE_RESET and GET_PREVIOUS_NET_READING, invoked inline to derive the previous reading and previous net reading for each row.
• CSI_LOOKUPS (VIEW) — supplies MISC_READING_TYPE_DESC via the ADJUSTMENT_TYPE lookup.
• CSI_TRANSACTIONS (SYNONYM) — supplies SOURCE_HEADER_REF_ID, exposed as SOURCE_TRANSACTION_ID.
• CSI_TXN_TYPES (SYNONYM) — supplies the decoded SOURCE_TRANSACTION_CODE via TRANSACTION_TYPE_ID (81=CONTRACT_LINE, 80=CP, 85=OKL_CNTR_GRP, 86=FS, 87=DR).

Key Columns

• ROW_ID / OBJECT_VERSION_NUMBER — ROWID and optimistic locking version from the reading row.
• COUNTER_GRP_LOG_ID — alias of TRANSACTION_ID, linking the reading to its transaction log group.
• COUNTER_ID, COUNTER_VALUE_ID, COUNTER_GROUP_ID — identifiers joining readings to counters and counter groups.
• COUNTER_NAME, COUNTER_DESCRIPTION, TYPE, UOM_CODE, INITIAL_READING, TOLERANCE_PLUS, TOLERANCE_MINUS — counter definition attributes.
• VALUE_TIMESTAMP, COUNTER_READING, NET_READING — the reading date and the raw/net measured values.
• RESET_FLAG, RESET_REASON — derived reset indicator and reason.
• MISC_READING_TYPE, MISC_READING_TYPE_DESC, MISC_READING — adjustment type lookup and adjusted reading value.
• SOURCE_TRANSACTION_ID, SOURCE_TRANSACTION_CODE — originating transaction and its decoded type.
• PREV_COUNTER_READING, PREV_NET_READING — prior readings derived via the CSI_COUNTER_READINGS_PVT package functions.
• ROLLOVER_LAST_READING, ROLLOVER_FIRST_READING — rollover thresholds.
• DISABLED_F, START_DATE_ACTIVE, END_DATE_ACTIVE, attribute columns, and audit columns.

Common Use Cases and Queries

The view is typically queried for metered usage reporting, contract counter-group reconciliation (the classic OKL_CNTR_GRP scenario), and variance analysis against tolerances.

Sample query listing readings for a counter group:

SELECT counter_name, value_timestamp, counter_reading, net_reading, source_transaction_code
FROM apps.csi_counter_readings_bcv_v
WHERE counter_group_id = :p_group_id
ORDER BY value_timestamp;

Sample query surfacing OKL counter-group sourced readings:

SELECT counter_id, counter_name, net_reading, source_transaction_id
FROM apps.csi_counter_readings_bcv_v
WHERE source_transaction_code = 'OKL_CNTR_GRP';

Because the view invokes PL/SQL functions per row and joins multiple base objects, queries should be filtered aggressively on COUNTER_ID, COUNTER_GROUP_ID, or VALUE_TIMESTAMP to control execution cost.