Search Results parent_instance_number

Overview

EAM_WORK_ORDERS_V is a reporting view owned by the APPS schema within the Enterprise Asset Management (EAM) module of Oracle E-Business Suite. It consolidates maintenance work order information together with the service requests associated with those work orders, providing a single queryable interface over data otherwise distributed across Work in Process, Asset Management, Service, and Projects tables. The view is documented as VALID in both EBS 12.1.1 and 12.2.2 environments.

Its primary role is to support operational reporting, dashboards, and integration extracts where a consolidated picture of maintenance execution is required. The view text is anchored on WEO.ROW_ID and exposes WEO.WE_ROW_ID (aliased as WE_ROW_ID), which links each row back to the base work order entity. Because the view is defined in the APPS schema and selects from multiple synonym-backed objects, it is typically accessed with MO or custom responsibility-based grants rather than direct table privileges.

Underlying Base Objects

The view draws from a broad set of documented base objects. The core work order data originates from EAM_WORK_ORDER_DETAILS_V, WIP_ENTITIES, and WIP_DISCRETE_JOBS, which supply the WIP entity identity, naming, status, and scheduling attributes. Asset and item context is enriched through CSI_ITEM_INSTANCES, MTL_SYSTEM_ITEMS, MTL_SYSTEM_ITEMS_KFV, and MTL_PARAMETERS, giving asset number, asset description, primary item, and organization defaults.

Failure and completion information is sourced from EAM_ASSET_FAILURES, EAM_ASSET_FAILURE_CODES, and EAM_JOB_COMPLETION_TXNS. Service request association is achieved through CS_INCIDENTS_B_SEC and EAM_WO_SERVICE_ASSOCIATION. Hierarchical and scheduling relationships are resolved via EAM_WO_RELATIONSHIPS and WIP_SCHEDULE_GROUPS. Department and owning-organization data come from BOM_DEPARTMENTS, while project and task context is provided through the PJM_PROJECT package. Descriptive lookups are decoded using MFG_LOOKUPS and FND_MESSAGE. Collectively, these objects explain why the view exposes both native work order identifiers and derived display columns such as STATUS_TYPE_DISP and WORK_ORDER_TYPE_DISP.

Key Columns

• ROW_ID / WE_ROW_ID — The primary work order row identifier and the underlying work order entity reference; WE_ROW_ID is the value most commonly used in join predicates to EAM_WORK_ORDER_DETAILS.
• WIP_ENTITY_ID, WIP_ENTITY_NAME — The WIP entity that backs the maintenance work order, used for cross-referencing with WIP and cost transactions.
• ORGANIZATION_ID — The inventory organization in which the work order is executed.
• ASSET_NUMBER, ASSET_DESCRIPTION, ASSET_GROUP_ID, PRIMARY_ITEM_ID — Asset and item identification attributes.
• STATUS_TYPE, STATUS_TYPE_DISP, WORK_ORDER_TYPE, WORK_ORDER_TYPE_DISP — Status and type codes along with their decoded display values.
• SCHEDULED_START_DATE, SCHEDULED_COMPLETION_DATE, DATE_RELEASED, DATE_COMPLETED, DATE_CLOSED — Lifecycle date stamps supporting aging and turnaround analysis.
• PROJECT_ID, TASK_ID, PROJECT_NUMBER, TASK_NUMBER — Project and task linkage for capitalized or project-driven maintenance.
• PARENT_WIP_ENTITY_ID, PARENT_WIP_ENTITY_NAME — Parent-child work order hierarchy.
• Account columns (MATERIAL_ACCOUNT, RESOURCE_ACCOUNT, OVERHEAD_ACCOUNT, and variance accounts) — Costing distribution references.

Common Use Cases and Queries

A frequent requirement is to list all open maintenance work orders for a given organization, resolving their assets and service requests. For example:

• SELECT wip_entity_name, asset_number, status_type_disp, scheduled_start_date FROM eam_work_orders_v WHERE organization_id = :org AND status_type <> 'CLOSED';
• SELECT a.wip_entity_name, a.service_request_id FROM eam_work_orders_v a WHERE a.we_row_id = :we_row_id;
• SELECT wip_entity_name, project_number, task_number, date_completed FROM eam_work_orders_v WHERE date_completed BETWEEN :from_date AND :to_date;

Because the underlying definition is complex and joins several views and packages, queries should filter on indexed columns such as ORGANIZATION_ID, WIP_ENTITY_ID, and WE_ROW_ID wherever possible, and avoid unfiltered full scans in high-volume reporting.