Search Results snap_left

Overview

WIP_EAM_PROCESS_WO_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Enterprise Asset Management (EAM) work order processing area within the Work in Process (WIP) module. The package provides a programmatic interface for manipulating EAM work orders — the maintenance work orders used to plan, schedule, and execute asset maintenance activities. Because it is classified as a PUB (public) API, it is intended for external invocation by other applications, forms, concurrent programs, and customer-written extensions rather than as an internal-only helper package.

The source header identifies the package as WIPPWOPS.pls, with an initial version dated December 2003. All procedures follow the Oracle Application Object Library (AOL) API standard, accepting the conventional p_api_version, p_init_msg_list, p_commit, and p_validation_level input parameters and returning x_return_status, x_msg_count, and x_msg_data output parameters. The package is declared AUTHID CURRENT_USER, so execution privileges are evaluated against the calling user rather than the package owner, which is characteristic of EAM work order maintenance APIs that must respect organization-level and asset-level security.

Key Procedures and Functions

The ETRM metadata documents five procedures in this package:

• UPDATE_FIRM_PLANNED_FLAG — Sets or clears the firm planned flag on a work order, identified by work order (WIP entity) and organization. This determines whether a planned work order is firmed against automatic rescheduling by the planning engine.
• MOVE_WO — Reschedules a work order by offsetting its start and/or completion dates. Documented parameters include the work object identifier and type, an offset in days (defaulting to one day), the offset direction (defaulting to forward), explicit start and completion dates, and a scheduling method (defaulting to forward scheduling). This supports both simple date-shifting and explicit re-dating of maintenance work orders.
• VALIDATE_STRUCTURE — Validates the work order structure, confirming that the work order and its associated asset hierarchy or operation structure are internally consistent before further processing.
• SNAP_RIGHT — Adjusts a work order's schedule to the next valid scheduling boundary in the forward (rightward) direction on the scheduling timeline, honoring the organization's workday calendar and scheduling constraints.
• SNAP_LEFT — The converse operation: adjusts a work order's schedule to the previous valid scheduling boundary in the backward (leftward) direction.

The SNAP_RIGHT and SNAP_LEFT procedures are the object of the search that surfaced this package. They are calendar-aware date alignment utilities used during work order scheduling to keep dates on valid working-day boundaries.

Tables Accessed

The ETRM extract for this package does not enumerate specific base tables. Based on the documented procedures and their parameters, the package operates against the core EAM/WIP work order tables accessed through APPS synonyms — principally the work order (WIP entity) and work order scheduling tables that store start dates, completion dates, firm planned status, and scheduling method, together with the organization and workday calendar definitions used by the snap procedures. Parameter naming such as p_wip_entity_id and p_organization_id confirms the organization-scoped nature of these updates.

Usage Notes

WIP_EAM_PROCESS_WO_PUB is typically invoked from the EAM work order maintenance forms, from concurrent programs that reschedule or firm work orders in bulk, and from customer-written PL/SQL or integration code that needs to programmatically adjust EAM work order scheduling. The ETRM metadata records no other packages referencing it, indicating it functions as a top-level public entry point rather than an internal dependency. Callers should always check x_return_status and retrieve messages via FND_MSG_PUB, and should set p_commit appropriately depending on whether they wish to manage the transaction boundary themselves. Organizations should treat this as a supported public API and avoid direct DML against the underlying work order tables.