Search Results get_wo_detail




Overview

MRP_RELEASE_EAM_WO is an Oracle E-Business Suite PL/SQL package body owned by APPS that supports the release of Enterprise Asset Management (EAM) work orders generated or staged by the planning and scheduling engine. Its principal role within the MSC/MRP flows is to consume records staged in the MSC_WIP_JOB_SCHEDULE_INTERFACE table — specifically EAM maintenance work orders flagged for release — and to drive the release of those work orders into the maintenance execution environment. The package operates against records associated with a supplied group identifier, allowing a batch of planned supply to be released as a cohesive unit. Processing is logged through MSC_UTIL logging utilities, with a debug verbosity level of one used for traceability. Release can be performed either against the local instance or across a database link, as indicated by the DB link parameter carried through the procedures. The header revision 120.3, dated 2011, places the package in the 12.1 and 12.2 release lineage, and it remains consistent with the 12.2.2 ETRM classification of OTHER (not a formal public API).

Key Procedures and Functions

The documented object exposes three procedures. Each is described below in terms of purpose; parameter lists are not reproduced.

  • RELEASE_EAM_WO — The main driver. It accepts a group identifier, a DB link, and a source instance identifier, then queries the work-order staging table for distinct source line and organization combinations matching that group. Only records with a maintenance object source flag of 1 and a load type of 257 are selected, which is the marker for EAM work orders in the scheduling interface. The procedure bulk-collects the resulting rows into a work-order table type, records the row count, and iterates over each entry, delegating the per-order logic to PROCESS_SINGLE_WO. It emits debug messages at the start of execution and returns an error buffer and return code to its caller.
  • PROCESS_SINGLE_WO — Handles the release of an individual work order, having been invoked once per staged record identified by RELEASE_EAM_WO. This is the procedure referenced by the search term "process_single_wo" and represents the granular unit of work within the package: it takes the per-order context assembled by the driver, performs the release operations for that single maintenance work order, and updates the interface staging record accordingly. Failure or success of individual releases is reported back through the driver's aggregate status.
  • GET_WO_DETAIL — A retrieval routine that resolves and returns the detail attributes of a work order required to perform the release. It supplies the data that PROCESS_SINGLE_WO depends upon, such as work order identity, organization, and quantity information.

Tables Accessed

The primary table read by this package is MSC_WIP_JOB_SCHEDULE_INTERFACE, referenced with a dynamically appended DB link. This staging table holds the work orders and supply schedule rows emitted by the planning process, and the release logic filters it by group identifier, maintenance object source, and load type. The documented table references for the package include PLITBLM and V$PARAMETER2, both accessed through APPS synonyms. PLITBLM is a temporary global table used internally by Oracle's PL/SQL infrastructure, typically for bulk operations such as the bulk collect performed in RELEASE_EAM_WO. V$PARAMETER2 is a dynamic performance view that exposes initialization parameter values; its presence suggests the package inspects instance parameters — for example to determine configuration or DB link behavior — before performing release. Staged records consumed during release are updated so that successfully processed work orders are not re-released on subsequent runs.

Usage Notes

This package is an internal component of the MSC/MRP release infrastructure rather than a public application programming interface. It is not referenced by other packages per the documented dependency data. In practice it is invoked by the planning release concurrent programs and the underlying planning engine, which pass the group identifier assigned when the plan's supply records were staged. The DB link parameter allows the same code to run in a distributed configuration where the planning source and the execution target reside in separate databases. Because the entry points are not documented as a supported API, custom code should generally invoke the standard concurrent program that wraps these procedures rather than calling RELEASE_EAM_WO or PROCESS_SINGLE_WO directly. Developers tracing a release failure will typically search on process_single_wo or RELEASE_EAM_WO in the log output, since debug messages are written through MSC_UTIL and FND_FILE at debug level one when logging is enabled. Organizations upgrading from 12.1.1 to 12.2.2 should note that the release of EAM work orders continues to flow through the same interface staging design, and that the load type and maintenance source flags used in the selection query define which rows are treated as EAM work orders.