Search Results eam_wo_statuses_b




Overview

EAM_WO_STATUSES_B is the base (non-translated) table in the Oracle EAM schema that stores the user-defined work order statuses available to an organization. In Oracle EBS 12.1.1 and 12.2.2, work order statuses control the lifecycle of an asset work order — from draft through release, execution, and closure — and can be seeded by Oracle or created and maintained by the customer. This table holds the language-independent attributes of each status, while the descriptive, translatable text is held in the companion table EAM_WO_STATUSES_TL. Statuses defined here are referenced across work order processing, safety plans, and user-defined safety statuses.

Under the heuristic Data Vault classification derived from the foreign-key structure, this object is modelled as a standalone table. In Data Vault terms it behaves primarily as a reference or hub-like construct keyed on STATUS_ID, with attributes describing the status. The classification is a modeling suggestion only; in ETP the table functions as an EAM reference/lookup entity rather than a transactional hub or link.

Key Information Stored

The table is documented with 10 columns, and the most operationally significant are listed below. The surrogate primary key is STATUS_ID, enforced by the constraint EAM_WO_STATUSES_B_PK. A unique index, EAM_WO_STATUSES_B_U1, spans STATUS_ID and ZD_EDITION_NAME; this composite is the business-key candidate that supports the multi-tenant editioning model introduced in 12.2.x.

  • STATUS_ID — the surrogate primary key and the identifier referenced by all dependent tables, including EAM_WO_STATUSES_TL, EAM_SAFETY_USR_DEF_STATUSES_TL, and work order records.
  • SEEDED_FLAG — indicates whether the status is Oracle-seeded (shipped) or user-defined, which determines whether it can be modified or deleted.
  • SYSTEM_STATUS — maps the user-defined status to the underlying system status used by EAM work order processing logic.
  • ENABLED_FLAG — controls whether the status is active and selectable in work order transactions.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard Oracle EBS audit columns recording who created and last modified the row and when.
  • ZD_EDITION_NAME — the editioning column supporting online patching and multi-tenant editioning in the 12.2.x release family.

Common Use Cases and Queries

Typical uses include listing enabled statuses for a work order type, resolving the system status behind a user-defined status, and reporting on status usage across work orders. The following pattern joins the base and translated tables to return descriptive status information.

  • Status lookup with description: SELECT b.status_id, t.description, b.system_status, b.enabled_flag FROM eam_wo_statuses_b b, eam_wo_statuses_tl t WHERE b.status_id = t.status_id AND t.language = USERENV('LANG');
  • Enabled statuses only: filter the above with b.enabled_flag = 'Y' to present only selectable statuses.
  • Seeded versus custom: query by seeded_flag to audit which statuses were delivered by Oracle and which the customer created.
  • Reporting: status descriptions are frequently embedded in work order and asset activity reports, requiring the join to EAM_WO_STATUSES_TL for a readable label.

Related Objects

The principal dependent objects are the two tables documented as foreign-key children, both of which reference EAM_WO_STATUSES_B by STATUS_ID.

  • EAM_WO_STATUSES_TL — join column EAM_WO_STATUSES_TL.STATUS_ID. Holds the language-dependent name and description for each status; every user-visible status label is resolved here.
  • EAM_SAFETY_USR_DEF_STATUSES_TL — join column EAM_SAFETY_USR_DEF_STATUSES_TL.STATUS_ID. Holds translations for user-defined safety statuses tied to the work order status definition.
  • Work order tables — records such as EAM_WORK_ORDERS reference the STATUS_ID to indicate each work order's current lifecycle state; joins resolve the status description.
  • EAM_STATUSES / master status configuration — related status definition and validation logic consumed by the EAM work order forms and APIs.

Because the object is classified as standalone, it has no upward foreign-key dependency on parent tables; it acts as a reference source that child tables and work order records depend upon.