Search Results eam_meters_u2




Overview

The EAM.EAM_METERS table is a core master data object within the Oracle E-Business Suite Enterprise Asset Management (EAM) module. It stores the meter templates and meter definitions that drive preventive maintenance and condition-based maintenance activities. Each row in this table represents either a reusable meter template or an actual meter definition, distinguished by the TMPL_FLAG column: when TMPL_FLAG equals 'Y' the row is a template, and when TMPL_FLAG equals 'N' or is null the row is a concrete meter definition. Meters are the instruments used to capture cumulative or point-in-time readings—such as odometer mileage, operating hours, or cycle counts—that trigger maintenance schedules and work order generation.

From a dimensional modeling perspective, the mined metadata classifies EAM_METERS as hub-leaning. This suggests that the table behaves as a business entity hub: it holds the durable identity of each meter (via METER_ID and METER_NAME) while transactional and associative facts about readings and asset assignment are captured in downstream tables. Modelers should therefore treat EAM_METERS as the anchor of a hub-and-link structure rather than as a satellite carrying rapidly changing descriptive attributes.

Key Information Stored

The table contains 37 documented columns. The most operationally significant are summarized below.

  • METER_ID — The surrogate primary key (EAM_METERS_PK) and the numeric identifier used by all foreign key references.
  • METER_NAME — The business-key candidate, enforced by unique index EAM_METERS_U2. It carries the human-readable meter name.
  • METER_UOM — The unit of measure in which readings are recorded (for example, miles, hours, or cycles).
  • VALUE_CHANGE_DIR — Indicates the permitted direction of value change (increasing, decreasing, or bidirectional).
  • USED_IN_SCHEDULING — Flag controlling whether the meter contributes to preventive maintenance scheduling.
  • USER_DEFINED_RATE — A manually supplied usage rate, used when automatic rate calculation is not desired.
  • USE_PAST_READING — Specifies how many historical readings are consumed to compute a rolling usage rate.
  • INITIAL_READING — The baseline reading recorded when the meter is first established.
  • METER_TYPE — Classifies the meter, supporting reporting and filtering by measurement category.
  • REQUIRED_FLAG — Indicates whether a reading is mandatory for the associated maintenance program.
  • TMPL_FLAG / SOURCE_TMPL_ID — Together they distinguish templates from definitions and link a definition back to the template it was created from.
  • MIGRATED_FLAG — Marks rows introduced through data migration, useful for reconciliation during implementations.
  • FROM_EFFECTIVE_DATE / TO_EFFECTIVE_DATE — Define the validity window of the meter record.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — Descriptive flexfield columns available for client-specific extensions.
  • Standard WHO columnsCREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide audit lineage.

Common Use Cases and Queries

Typical scenarios include identifying all meters eligible for scheduling, resolving the template a given meter was derived from, and reconciling migrated records. The following pattern retrieves active meter definitions that participate in scheduling:

  • SELECT meter_id, meter_name, meter_uom, meter_type FROM eam.eam_meters WHERE (tmpl_flag = 'N' OR tmpl_flag IS NULL) AND used_in_scheduling = 'Y' AND sysdate BETWEEN from_effective_date AND NVL(to_effective_date, sysdate);
  • To join meters to their assets and latest readings, query EAM_ASSET_METERS on METER_ID, then EAM_METER_READINGS on the same key, ordered by reading date descending.
  • To trace template lineage, self-join EAM_METERS while supplying an inline view filtered on TMPL_FLAG to avoid ambiguity between template and definition rows.
  • Reconciliation reporting commonly groups by MIGRATED_FLAG and METER_TYPE to confirm completeness after a conversion.

Related Objects

The FK metadata identifies several dependent tables that reference EAM_METERS through METER_ID:

  • EAM_ASSET_METERS — Associates meters with specific assets (EAM_ASSET_METERS.METER_ID → EAM_METERS.METER_ID).
  • EAM_METER_READINGS — Stores the transactional readings captured against each meter.
  • EAM_METER_READINGS_INTERFACE — The open interface staging table for loading meter readings from external systems.

Because EAM_METERS is hub-leaning, its principal relationships flow outward to these link and satellite-style objects, which hold the association and transactional detail that complements the meter master definition.