Search Results csi_ctr_estimated_readings_pk

Overview

The table CSI_CTR_ESTIMATED_READINGS resides in the CSI schema, which supports the Install Base product within Oracle E-Business Suite, and is documented as VALID in both release 12.1.1 and 12.2.2. Its stated purpose is to hold counter estimated readings data. Counters in the Install Base model represent measurable quantities attached to an installed asset, such as meter readings, odometer values, or usage counters. Because physical readings are not always captured at every interval, EBS derives estimated values through an averaging or interpolation process, and this table persists the output of that estimation logic. Each record therefore represents a single estimated value for a given counter over a defined measurement period.

The heuristic Data Vault classification mined from the foreign key structure is standalone. In dimensional modeling terms, the table behaves more like a satellite attached to a counter or estimation parent than as an independent hub, since its rows are descriptive measurements dependent on an external estimation process. This classification should be treated as a modeling suggestion rather than a normative statement, as the object carries no independent business identity of its own.

Key Information Stored

The surrogate primary key is ESTIMATED_READING_ID, enforced by the constraint CSI_CTR_ESTIMATED_READINGS_PK and mirrored in the unique index CSI_CTR_ESTIMATED_READINGS_U01. The table contains 34 documented columns. The most significant are:

• ESTIMATED_READING_ID — the surrogate key uniquely identifying each estimated reading record.
• COUNTER_ID — identifies the install base counter to which the estimate pertains.
• ESTIMATION_ID — links the reading to the estimation run or process that produced it.
• VALUE_TIMESTAMP — the effective point in time that the estimated reading represents.
• ESTIMATED_METER_READING — the derived absolute counter value.
• ESTIMATED_USAGE — the derived consumption between period boundaries.
• NUM_OF_READINGS — count of actual readings used in the estimation.
• PERIOD_START_DATE / PERIOD_END_DATE — boundaries of the estimated interval.
• AVG_CALCULATION_START_DATE — lower bound of the window used to compute averages.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enforcing multi-tenant data access.
• OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, CREATED_BY — standard concurrency and audit columns.
• MIGRATED_FLAG — indicates records carried forward during migration.

Fifteen ATTRIBUTE columns provide the standard EBS descriptive flexfield extension capacity.

Common Use Cases and Queries

The dominant reporting scenario is reconstructing usage history for an installed asset where physical readings were missed. A typical query joins the counter and estimation parents:

• Retrieving the estimate series for one counter: SELECT VALUE_TIMESTAMP, ESTIMATED_METER_READING, ESTIMATED_USAGE FROM CSI_CTR_ESTIMATED_READINGS WHERE COUNTER_ID = :counter_id ORDER BY VALUE_TIMESTAMP;
• Auditing an estimation run: filter on ESTIMATION_ID and compare NUM_OF_READINGS against expected cadence.
• Billing or contract reconciliation, where ESTIMATED_USAGE between PERIOD_START_DATE and PERIOD_END_DATE feeds charge calculations.
• Data-quality checks identifying periods where AVG_CALCULATION_START_DATE is unusually distant, signalling unreliable estimates.
• Migration validation using MIGRATED_FLAG to separate legacy-sourced rows from organically generated ones.

All queries should respect SECURITY_GROUP_ID when operating in a multi-org or multi-tenant environment.

Related Objects

The documented foreign key relationship is CSI_CTR_ESTIMATED_READINGS.SECURITY_GROUP_ID → FND_SECURITY_GROUPS, which governs row-level access control. Beyond this, the object participates operationally with the Install Base counter and estimation infrastructure, most significantly CSI_COUNTERS (joined on COUNTER_ID), the counter reading tables that supply actual values for averaging, the estimation header objects referenced by ESTIMATION_ID, and the standard EBS audit and flexfield support tables. Because the mined classification is standalone, the FK structure is deliberately thin and integrity for COUNTER_ID and ESTIMATION_ID is maintained at the application layer rather than by database constraint, a pattern that should be verified when building integration or analytical extracts.