Search Results move_wo

Overview

APPS.EAM_WO_NETWORK_UTIL_PVT is a private (PVT) PL/SQL utility package within the Oracle Enterprise Asset Management (eAM) module. Its purpose is to support the rescheduling and movement of work orders that are associated with a work order network — that is, a collection of related work objects (work orders and their dependent operations) whose execution dates are governed by scheduling relationships. In the eAM model, work orders can be linked through predecessor/successor relationships, and moving one work order may require recalculating the dates of downstream or upstream objects. This package encapsulates that date-shifting logic so that callers do not have to manually traverse the work order network and update scheduling dates themselves.

The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking session rather than the defining schema. It is classified as a private API, which indicates it is intended for internal use by other eAM packages and forms rather than as a public integration interface. The header identifies the source file as EAMVWNUS.pls and notes initial creation in September 2003 by Basanth Roy. The package is referenced by four other packages in the EBS environment, confirming its role as a shared internal utility.

Key Procedures and Functions

The package exposes two documented procedures:

• Move_WO — The primary procedure for relocating a work order within the schedule. It accepts a work object identifier and work object type identifier to locate the target, and then applies an offset expressed in days and a direction (forward or backward) to shift the schedule. Callers may alternatively supply explicit start and completion dates, and select a scheduling method such as forward scheduling. A flag controls whether firm (firmed) work orders are permitted to be moved. Following the standard EBS API convention, the procedure returns a return status, a message count, and message data output parameters, and honors initialization, commit, and validation-level parameters.
• Schedule_for_Move — A related procedure that performs the scheduling calculations required to support a subsequent move. It accepts the same work object identifiers and offset parameters, along with a scheduling method, and returns the standard status and message outputs. This procedure is typically used to determine or prepare the rescheduled dates for objects within the network before the move is finalized.

No public functions are documented in the ETRM metadata; the package is entirely procedure-driven.

Tables Accessed

The package reads and writes against core Work in Process (WIP) and inventory tables, accessed through APPS synonyms:

• WIP_DISCRETE_JOBS — the primary work order header table, where scheduling and status information is maintained and updated during a move.
• WIP_OPERATIONS and WIP_REQUIREMENT_OPERATIONS — hold operation-level scheduling detail; these are consulted and adjusted so that operation dates remain consistent with the moved work order.
• WIP_OPERATION_RESOURCES, WIP_OPERATION_RESOURCE_USAGE, and WIP_OP_RESOURCE_INSTANCES — capture resource assignments and usage at the operation level, which may require date alignment when operations shift.
• WIP_SCHED_RELATIONSHIPS — defines the predecessor/successor links that constitute the work order network; this table drives the traversal logic that determines which dependent objects must also move.
• MTL_SYSTEM_ITEMS_B — the item master, used to resolve item attributes relevant to scheduling behavior.

Usage Notes

Because EAM_WO_NETWORK_UTIL_PVT is a private package, it is not documented for direct customer invocation. It is typically called by other eAM packages — the ETRM metadata records four referring packages — and by eAM maintenance work order forms that allow a planner to shift a work order and cascade the change across its network. Custom code should avoid calling private APIs directly, since their signatures are not guaranteed across releases; where rescheduling functionality is required, supported public APIs or the standard eAM forms should be used instead. When invoked, the procedures participate in the caller's transaction, and commit behavior is controlled by the p_commit flag in keeping with standard EBS API conventions.