Search Results complete_workorder




Overview

EAM_WORKORDERS_JSP is a server-side PL/SQL package body in the Oracle E-Business Suite Enterprise Asset Management (EAM) module. It belongs to the APPS schema and is classified as an "OTHER" API in the ETRM repository for releases 12.1.1 and 12.2.2. The package provides the programmatic backbone for creating, updating, completing, and structuring Work Orders (also called work orders or maintenance work orders) within the EAM work management flow.

The header comment ($Header: EAMJOBJB.pls 120.16.12020000.3 2012/12/05) indicates that the current version was stabilized at the 12.1.3 / 12.2 code line. The package name suffix "_JSP" suggests it was originally designed to support the Java Server Page (JSP) based EAM Work Order web pages, which is consistent with its role as a business-logic layer between the EAM user interface and the underlying EAM_PROCESS_WO_PUB APIs. The body declares a package-level constant G_PKG_NAME and a debug variable g_debug_sqlerrm, and it relies heavily on FND_API boilerplate (standard IN/OUT parameters such as p_api_version, p_init_msg_list, p_commit, x_return_status, x_msg_count, x_msg_data) for consistent error handling.

Notably, the package body defines local record and table variables based on EAM_PROCESS_WO_PUB types (eam_wo_rec_type, eam_op_tbl_type, eam_op_network_tbl_type, eam_res_tbl_type), confirming that it is a wrapper/enhancer around the public EAM Work Order processing API rather than a standalone data-access layer.

Key Procedures and Functions

The documented procedures and functions cover the full work-order lifecycle:

  • ADD_EXIST_WORK_ORDER — Adds an existing work order into a hierarchy or structure, accepting organization, WIP entity, firm flag, parent WIP, and relation-type parameters. It operates on EAM_PROCESS_WO_PUB record types to mirror the standard EAM structure API.
  • COMPLETE_WORKORDER — The procedure most relevant to the search term "complete_workorder." It finalizes a work order, driving the completion transaction path used by EAM maintenance execution.
  • CREATE_EZ_WORK_ORDER — Provides an "easy" or simplified work-order creation entry point, typically for quick or ad-hoc work orders.
  • UPDATE_WORK_ORDER — Modifies an existing work order's attributes.
  • VALIDATE_CANCEL — Performs pre-cancellation validation checks before a work order is cancelled.
  • GET_COMPLETION_DEFAULTS — Retrieves default values required at the point of work-order completion (e.g., default completion subinventory, locator, or transaction quantities).
  • ADD_WORKORDER_DEPENDENCY — Creates a dependency relationship between two work orders (finish-to-start, start-to-start, etc.).
  • DELETE_WORKORDER_DEPENDENCY — Removes an existing work-order dependency.
  • RESIZE_WO_HIERARCHY_PVT — Private helper that recalculates or resizes the work-order hierarchy after structural changes.
  • CREATE_COST_HIERARCHY_PVT — Private helper that builds the cost roll-up hierarchy for a work-order structure.

Tables Accessed

The package reads and writes a focused set of EAM and inventory tables through APPS synonyms:

Usage Notes

EAM_WORKORDERS_JSP is an internal-facing package with no documented callers among other packages ("Referenced by 0 other packages"), indicating it is invoked primarily from the EAM Work Order JSP-based web pages and, potentially, from custom forms or concurrent programs that need to drive work-order completion or hierarchy changes.

Because it exposes FND_API-style signatures and delegates to EAM_PROCESS_WO_PUB, callers must follow standard EBS API conventions: initialize the message list, check x_return_status for FND_API.G_RET_STS_SUCCESS, and handle errors via x_msg_count/x_msg_data. Custom code should call COMPLETE_WORKORDER only after validating that completion defaults are available via GET_COMPLETION_DEFAULTS, and should use VALIDATE_CANCEL before invoking cancellation logic. Given the "_PVT" suffix on RESIZE_WO_HIERARCHY_PVT and CREATE_COST_HIERARCHY_PVT, these two routines are private helpers and should not be invoked directly by external code; they are triggered internally during dependency and structure changes.