Search Results eam_meters




Overview
Explore in AI Chat

Overview

EAM_METERS is the master definition table for asset meters within the Oracle E-Business Suite Enterprise Asset Management (EAM) module. In Oracle EBS 12.1.1 and 12.2.2, a "meter" represents a measurable counter or gauge attached to an asset — examples include odometer readings, runtime hours, cycle counts, or temperature thresholds. The EAM_METERS table holds the reusable definitions for those meters: their unit of measure, directional behavior, scheduling participation, and validation rules. It does not itself store the readings taken against an asset; those transactions are held in EAM_METER_READINGS, while the association of a meter to a specific asset is captured in EAM_ASSET_METERS.

The table is owned by the EAM schema and contains 37 documented columns. Based on the mined foreign-key topology, the ETRM metadata classifies EAM_METERS as hub-leaning in Data Vault terms. This is a modeling suggestion rather than a physical implementation attribute: the table behaves as a stable, business-key-identified entity referenced by multiple dependent tables, which is characteristic of a hub rather than a link or satellite.

Key Information Stored

The surrogate primary key of EAM_METERS is METER_ID, enforced by the constraint EAM_METERS_PK. Two unique indexes act as business-key candidates: EAM_METERS_U1 on METER_ID and EAM_METERS_U2 on METER_NAME, meaning the meter name must be unique across the enterprise. The most significant columns fall into definitional, behavioral, and governance categories:

Common Use Cases and Queries

Typical reporting scenarios include listing schedulable meters, auditing meter definitions prior to a maintenance program rollout, and reconciling readings to their parent definitions. A simple lookup joining the definition to its readings follows a pattern such as:

SELECT m.meter_name, m.meter_uom, m.value_change_dir, r.reading_value, r.reading_date FROM eam.eam_meters m, eam.eam_meter_readings r WHERE m.meter_id = r.meter_id AND m.used_in_scheduling = 'Y' ORDER BY r.reading_date DESC;

To identify where a meter is deployed, join through the association table on asset_id. Migration and setup audits can filter on MIGRATED_FLAG or TMPL_FLAG, and effective-date checks compare SYSDATE against the FROM_EFFECTIVE_DATE and TO_EFFECTIVE_DATE columns. Because METER_NAME is uniquely indexed, name-based lookups resolve to a single definition row.

Related Objects

EAM_METERS is referenced by three dependent objects documented in the ETRM relationship data:

  • EAM_ASSET_METERS — join on EAM_ASSET_METERS.METER_ID = EAM_METERS.METER_ID; associates a meter definition with a specific asset.
  • EAM_METER_READINGS — join on EAM_METER_READINGS.METER_ID = EAM_METERS.METER_ID; stores the transactional readings captured against meters.
  • EAM_METER_READINGS_INTERFACE — join on METER_ID; the open interface used to load external meter readings before validation against the definition.

Together these objects form the three-tier meter model: definition (EAM_METERS), asset association (EAM_ASSET_METERS), and measurements (EAM_METER_READINGS and its interface). Direct inserts or updates against EAM_METERS should be avoided in favor of the EAM maintenance setup forms and supported APIs, since validation and effective-dating logic is enforced at the application layer.