Search Results create_ez_work_order

Overview

APPS.EAM_WORKORDERS_JSP is a PL/SQL package belonging to Oracle Enterprise Asset Management (eAM), the module of Oracle E-Business Suite responsible for maintaining assets and executing maintenance work orders. The package name reflects its original design intent: to provide server-side PL/SQL functionality for the Java Server Pages (JSP) user interface through which maintenance activities are entered and executed. As the source header of the package indicates, its stated purpose is to expose "eam work order functionalities" — that is, the create, update, completion, cancellation, and dependency-management operations that a user performs against an eAM work order.

In Oracle EBS 12.1.1 and 12.2.2, the package is owned by APPS and is classified as an OTHER API. It is not a public, externally supported interface in the same sense as a documented PL/SQL API, but it is used internally by the eAM work order pages and by related PL/SQL logic. The package declares standard WHO columns derived from FND_GLOBAL (user identifier, login identifier, concurrent request, program application, and program identifiers) at the package level, which are applied to the records it creates and updates. The package header carries the version marker $Header: EAMJOBJS.pls 120.2 2006/03/21 and is marked noship, indicating that it is a shipped but internally consumed component rather than a customer-facing API.

Key Procedures and Functions

The package exposes ten documented procedures and functions. VALIDATE_CANCEL evaluates whether a given work order, identified by WIP entity, is eligible for cancellation and is called before the cancellation action is allowed to proceed. ADD_EXIST_WORK_ORDER adds an existing work order into the eAM work order structure, supporting firming and parent/child relationships through parameters such as organization, WIP entity, firm flag, parent WIP identifier, and relation type, and follows the standard PL/SQL API conventions of API version, initialization of the message list, commit control, validation-only mode, record version number, and the standard return status, message count, and message data outputs.

COMPLETE_WORKORDER is a wrapper around EAM_COMPLETION.COMPLETE_WORK_ORDER that captures the return status and appends messages to the message list so that JSP pages can retrieve them. CREATE_EZ_WORK_ORDER supports rapid or simplified creation of a work order. UPDATE_WORK_ORDER applies modifications to an existing work order. GET_COMPLETION_DEFAULTS returns default completion information for use by the completion pages. ADD_WORKORDER_DEPENDENCY and DELETE_WORKORDER_DEPENDENCY maintain predecessor/successor relationships between work orders. Two private helper procedures, RESIZE_WO_HIERARCHY_PVT and CREATE_COST_HIERARCHY_PVT, recalculate the work order hierarchy and build the associated cost hierarchy.

Tables Accessed

The package reads and writes a range of eAM, inventory, and service tables through APPS synonyms. Work order relationship and status data are held in EAM_WO_RELATIONSHIPS and EAM_WO_STATUSES_V. Completion activity is recorded in EAM_JOB_COMPLETION_TXNS and EAM_OP_COMPLETION_TXNS. Organization-level defaults come from EAM_ORG_MAINT_DEFAULTS, while service associations are stored in EAM_WO_SERVICE_ASSOCIATION and EAM_WO_SERVICE_ASSOCIATION_S. Inventory and item context is supplied by MTL_PARAMETERS, MTL_ITEM_SUB_INVENTORIES, MTL_SECONDARY_INVENTORIES, MTL_SECONDARY_LOCATORS, MTL_LOT_NUMBERS, and BOM_DEPARTMENTS. Installed asset and incident context is drawn from CSI_ITEM_INSTANCES and CS_INCIDENTS_ALL_B.

Usage Notes

EAM_WORKORDERS_JSP is invoked primarily from the eAM work order JSP pages within the Maintenance Workbench and related maintenance super user responsibilities. Because it is a noship internal package, Oracle does not document it as a supported public API; no other packages in the documented set reference it. Customizations should therefore call the underlying public eAM APIs (such as EAM_COMPLETION) rather than this package directly. Where the package is called, callers should honor the standard API parameter conventions, checking x_return_status and consuming the message stack produced by x_msg_count and x_msg_data.