Search Results initial_reading




Overview
Explore in AI Chat

Overview

The OKX_COUNTERS_V view is a reporting and integration construct owned by the APPS schema within the OKX – Contracts Integration product module. Its documented purpose is to expose counters, counter instances, and counter templates in a single denormalized result set. In the Oracle EBS 12.1.1 and 12.2.2 architectures, OKX serves as the integration layer between Oracle Service Contracts and the Oracle Installed Base (CSI) counter infrastructure, allowing contract authors and downstream processes to reference usage-based metering data such as meter readings and consumption values.

The view carries a status of VALID and presents a merged picture: counter definition attributes sourced from the counters entity, joined to the latest counter reading for each counter. This design means that consumers do not need to independently resolve which reading is current; the view resolves the most recent reading through a server-side function call. The Oracle Proprietary, Confidential Information notice applies to the definition and its documentation.

Underlying Base Objects

The documented referenced base objects are:

  • CSI_COUNTERS_BC_V (VIEW) – the business-component view supplying counter header attributes such as name, type, group, active dates, and unit of measure.
  • CSI_COUNTER_READINGS (SYNONYM) – the readings source, joined to the latest reading per counter.
  • OKS_AUTH_UTIL_PVT (PACKAGE) – the service contracts authorization utility package used in the OKX integration flow.

The view text defines an outer join from CSI_COUNTERS_BC_V (aliased C) to CSI_COUNTER_READINGS (aliased CV). The join predicate on COUNTER_VALUE_ID is filtered by CSI_COUNTER_READINGS_PVT.GET_LATEST_READING(C.COUNTER_ID), ensuring each counter row returns at most one—its latest—reading. Both join conditions are marked with the Oracle outer-join operator (+), so counters without readings are still returned. Because the view is built on another view rather than directly on a base table, no DML is possible against it.

Key Columns

  • COUNTER_ID – primary identifier of the counter; also surfaced as ID1, with ID2 hard-coded to '#' to form a composite key convention used by OKX integration screens.
  • COUNTER_GROUP_ID – grouping identifier for related counters.
  • NAME, DESCRIPTION, TYPE – descriptive and classification attributes.
  • START_DATE_ACTIVE, END_DATE_ACTIVE – the effective window of the counter.
  • CREATED_FROM_COUNTER_TMPL_ID and SOURCE_COUNTER_ID – template lineage; note that SOURCE_COUNTER_ID is an alias of the same underlying template column.
  • INITIAL_READING, UOM_CODE, USAGE_ITEM_ID – baseline reading, unit of measure, and the inventory item used for usage billing.
  • CTR_VAL_MAX_SEQ_NO – highest sequence number for counter values.
  • COUNTER_VALUE_ID, VALUE_TIMESTAMP, COUNTER_READING, NET_READING – attributes of the latest reading.
  • STATUS – derived through nested DECODE(SIGN(...)) expressions comparing TRUNC(SYSDATE) to the active date range; returns 'A' for active or 'I' for inactive.
  • PRIMARY_UOM_CODE – mirrors UOM_CODE for the primary unit of measure.

Common Use Cases and Queries

Typical scenarios include contract usage verification, counter lifecycle reporting, and integration extraction of meter readings for Service Contracts billing. A baseline query lists active counters with their latest reading:

  • SELECT counter_id, name, type, status, counter_reading, net_reading, value_timestamp FROM okx_counters_v WHERE status = 'A';
  • SELECT counter_id, name, ctr_val_max_seq_no FROM okx_counters_v WHERE counter_reading IS NULL; – identifies counters with no reading captured.
  • SELECT counter_group_id, COUNT(*) FROM okx_counters_v GROUP BY counter_group_id; – counter population by group.
  • SELECT source_counter_id, COUNT(*) FROM okx_counters_v WHERE source_counter_id IS NOT NULL GROUP BY source_counter_id; – template-derived counter counts.

Because STATUS and the latest-reading resolution are computed at query time, filters on those expressions should be applied in the outer query, and no direct DML against the view should be attempted.