Results for “workorder_name”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

In Oracle E-Business Suite, the table AHL_WORKORDERS (owned by the AHL schema) is the central repository for Production Work Order information within the Complex Maintenance Repair and Overhaul (CMRO) module. A work order in this context represents an executable maintenance or repair instruction derived from a maintenance visit and its associated route and operations. Each row captures the lifecycle state, scheduling, and linkage of a single production work order, making the table the operational anchor for executing, tracking, and reporting on maintenance activity across the AHL product.

From a Data Vault modeling perspective, the FK structure of this table suggests it functions as a hub. Its primary key, WORKORDER_ID, is a surrogate identifier that is referenced by numerous downstream transactional and dependent tables, which is characteristic of a hub entity acting as the stable business key around which descriptive satellites and relationship links are organized. This classification is heuristic and is offered purely as a modeling suggestion rather than a documented constraint.

Key Information Stored

The table contains 43 documented columns. The most significant include:

• WORKORDER_ID — The surrogate primary key (constituent of AHL_WORKORDERS_PK) and the identifier referenced by all dependent tables.
• WORKORDER_NAME — The business-facing name of the work order, backed by unique index AHL_WORKORDERS_U1.
• WIP_ENTITY_ID — The associated WIP entity, a strong business-key candidate enforced by AHL_WORKORDERS_U2 linking to WIP_ENTITIES.
• VISIT_ID and VISIT_TASK_ID — Foreign keys tying the work order to its parent maintenance visit (AHL_VISITS_B) and visit task (AHL_VISIT_TASKS_B).
• ROUTE_ID — The reference to the routing definition (AHL_ROUTES_B) that governs the operations to be performed.
• PLAN_ID — The quality plan (QA_PLANS) applied to the work order.
• STATUS_CODE — The current lifecycle status of the work order.
• ACTUAL_START_DATE and ACTUAL_END_DATE — Recorded execution timestamps.
• MASTER_WORKORDER_FLAG and CONFIRM_FAILURE_FLAG — Control flags governing master/subordinate relationships and failure confirmation behavior.
• MAINTENANCE_TYPE_CODE and AOG_FLAG — Classify the maintenance type and whether the work order is Aircraft-on-Ground priority.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS controlling data access.

Common Use Cases and Queries

Typical reporting scenarios include tracking open work orders by visit, measuring actual versus planned execution times, and identifying AOG-priority work. A common query joins the hub to its visit and route context:

SELECT w.WORKORDER_NAME, w.STATUS_CODE,
       w.ACTUAL_START_DATE, w.ACTUAL_END_DATE,
       v.VISIT_NAME
FROM   AHL_WORKORDERS w,
       AHL_VISITS_B    v
WHERE  w.VISIT_ID = v.VISIT_ID
AND    w.STATUS_CODE NOT IN ('CLOSED','CANCELLED');

Operational use cases include retrieving all operations for a work order via AHL_WORKORDER_OPERATIONS.WORKORDER_ID and reconciling material movements through AHL_WORKORDER_MTL_TXNS.NON_ROUTINE_WORKORDER_ID. Because WORKORDER_ID is referenced so widely, it is the natural join key for any cross-table maintenance analysis.

Related Objects

• AHL_VISITS_B — joined via AHL_WORKORDERS.VISIT_ID; the parent visit.
• AHL_ROUTES_B — joined via ROUTE_ID; defines the routing.
• AHL_WORKORDER_OPERATIONS — references this hub via WORKORDER_ID; holds operation-level detail.
• AHL_WORKORDER_MTL_TXNS — references via NON_ROUTINE_WORKORDER_ID; material transactions.
• AHL_WORKORDER_TXNS — references via WORKORDER_ID; transactional history.
• WIP_ENTITIES — joined via WIP_ENTITY_ID.
• AHL_OSP_ORDER_LINES and AHL_PART_CHANGES — dependent tables referencing WORKORDER_ID.
• QA_PLANS — joined via PLAN_ID.