Search Results eam_meter_readings_u1




Overview

The EAM.EAM_METER_READINGS table stores the transactional meter reading history captured against asset meters in Oracle Enterprise Asset Management. Each record represents a single reading event for a meter, preserving both the point-in-time value and the accumulated life-to-date value. This distinction is essential because EAM supports two meter behaviours: absolute meters, where the reading reflects the current total on the device, and change meters, where each reading records the delta from the prior reading. Downstream preventive maintenance scheduling, condition-based maintenance triggers, and work order generation all depend on this table to evaluate whether an asset has crossed a defined threshold.

From a Data Vault modelling perspective, the mined relationship structure suggests this object behaves as a link entity—it connects a meter (via METER_ID) to a work order context (via WIP_ENTITY_ID) while carrying descriptive and measurable payload. It can equally be treated as a satellite on the EAM_METERS hub, since the reading values and dates are descriptive attributes of the meter over time. The heuristic classification is offered as a modelling suggestion rather than a normative rule.

Key Information Stored

The table is defined with 34 columns in the documented 12.2.2 schema. The most significant include:

The unique index EAM_METER_READINGS_U1 is the principal business-key candidate, though METER_ID combined with CURRENT_READING_DATE is the more natural business identifier.

Common Use Cases and Queries

Typical reporting scenarios include meter reading history per asset, usage trending, overdue-reading detection, and reconciliation of work-order-driven readings. A representative query joins the meter definition to its latest reading:

  • Latest reading per meter: SELECT METER_ID, MAX(CURRENT_READING_DATE) FROM EAM_METER_READINGS GROUP BY METER_ID, then join back for CURRENT_READING and LIFE_TO_DATE_READING.
  • Readings for a specific meter over a date range: filter on METER_ID and CURRENT_READING_DATE, leveraging index EAM_METER_READINGS_N2.
  • Work-order-related readings: join on WIP_ENTITY_ID to WIP_DISCRETE_JOBS, using index EAM_METER_READINGS_N1.
  • Excluding inactive or migrated rows: add predicates DISABLE_FLAG = 'N' AND MIGRATED_FLAG = 'N'.

Because the table is transactional and can grow large, queries should always be index-driven on METER_READING_ID, METER_ID, or WIP_ENTITY_ID.

Related Objects

  • EAM.EAM_METERS — parent entity; joined on METER_ID = EAM_METERS.METER_ID. Provides meter name, unit of measure, and meter type.
  • WIP.WIP_DISCRETE_JOBS — joined on WIP_ENTITY_ID = WIP_DISCRETE_JOBS.WIP_ENTITY_ID; associates readings with discrete work orders.
  • EAM.EAM_METER_READINGS_PK — primary key constraint on METER_READING_ID.
  • EAM_METER_READINGS_U1 / _N1 / _N2 — the unique and non-unique indexes described above.
  • EAM work order and maintenance APIs (e.g., EAM_METER_READING public APIs) — programmatic entry points that insert and update rows here.
  • EAM preventive maintenance scheduling logic — consumes LIFE_TO_DATE_READING to trigger maintenance activity generation.