Search Results eam_failure_codes_u1

Overview

EAM.EAM_FAILURE_CODES is a reference definition table within the Oracle Enterprise Asset Management (EAM) module of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. It stores the master list of failure codes used to categorize the first symptom reported when an asset failure occurs. As illustrated in the ETRM documentation, a failure code such as PRNTRJAM would carry a description of "Printer Jam," providing a standardized vocabulary for capturing failure information across an organization.

The table functions as the prerequisite foundation for failure analysis configuration: failure codes must be defined here before failure combinations can be assembled and applied during the capture of failure information in work orders and maintenance activities. Under the heuristic Data Vault classification derived from its foreign-key structure, EAM_FAILURE_CODES is modeled as a standalone object. This classification suggests treating it as a reference or lookup hub, since it holds no foreign-key dependencies on other tables and serves purely as a controlled vocabulary source for downstream transactional records.

Key Information Stored

The table is defined physically in the EAM schema, resides in the APPS_TS_TX_DATA tablespace with a PCT FREE of 10, and contains eight documented columns.

• FAILURE_CODE (VARCHAR2, 80, mandatory): The unique identifier and business key for the failure code. This column is the target of both the primary key EAM_FAILURE_CODES_PK and the unique index EAM_FAILURE_CODES_U1, making it the natural business-key candidate that users search and reference directly.
• DESCRIPTION (VARCHAR2, 2000): The human-readable description of the failure code, supporting values up to 2000 characters.
• EFFECTIVE_END_DATE (DATE): The date beyond which the failure code is considered inactive, enabling soft retirement of codes without deleting historical references.
• Standard Who columns: CREATED_BY, CREATION_DATE, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE, and LAST_UPDATED_BY provide audit and concurrency information maintained automatically by the EBS framework.

Because FAILURE_CODE itself is the primary key—rather than an anonymous surrogate—there is no separate system-generated identifier column; the business key and the primary key coincide, which is typical for compact EAM reference tables.

Common Use Cases and Queries

The primary use case is populating and validating the failure code list-value domain used when maintenance personnel record failure information on assets. Administrators define codes here, and the downstream failure combination setup consumes them. Reporting use cases include failure frequency analysis, Pareto analysis of recurring failure modes, and identifying obsolete codes via EFFECTIVE_END_DATE.

A basic extraction query follows the documented pattern:

• SELECT FAILURE_CODE, DESCRIPTION, EFFECTIVE_END_DATE FROM EAM.EAM_FAILURE_CODES WHERE EFFECTIVE_END_DATE IS NULL OR EFFECTIVE_END_DATE > SYSDATE; — returns active failure codes only.
• Filter by FAILURE_CODE LIKE 'PRNTR%' to locate codes by naming convention.
• Join to failure combination tables on FAILURE_CODE to reconcile defined codes against configured combinations.
• Aggregate work order failure records by FAILURE_CODE to rank the most frequently reported failure modes.

Related Objects

According to the ETRM dependency data, EAM_FAILURE_CODES does not reference any other database object, confirming its standalone role. It is referenced by the APPS synonym EAM_FAILURE_CODES, which exposes the table to application code and forms-based setup. Downstream EAM objects that consume failure codes include the failure combination definition entities and the failure information capture structures attached to work orders, all of which resolve their failure code values by joining on the FAILURE_CODE column. Because the metadata documents no explicit foreign keys targeting this table, dependent relationships are enforced at the application layer rather than through database constraints, meaning integrity checks rely on EAM setup validation logic.