Search Results update_req_dates

Overview

WIP_SCHEDULING is a public PL/SQL package owned by APPS that supports the scheduling and rescheduling of discrete jobs within Oracle Work in Process. Its central purpose is to provide a controlled, validated path for loading scheduling data into the WIP_SCHEDULING_INTERFACE staging table and subsequently moving that validated data into the operational WIP tables. The package bridges the gap between externally supplied or programmatically generated scheduling requests and the core job, operation, and resource records maintained by the application.

The package is declared with AUTHID CURRENT_USER, so execution privileges are resolved against the calling schema rather than the definer. This makes invocation context relevant for custom callers. The header comment identifies a long-standing source line (wipsilds.pls), confirming it is an Oracle-shipped, versioned object rather than customer code. The metadata note that WIP_SCHEDULING is not referenced by any other package indicates it functions as a top-level entry point rather than a shared internal library.

Key Procedures and Functions

The package exposes eleven documented procedures, organized around the load-validate-apply workflow:

• LOAD_INTERFACE — Inserts scheduling records into WIP_SCHEDULING_INTERFACE for a job identified by P_WIP_ENTITY_ID. It creates one record per operation when P_SCHEDULING_LEVEL = 1, or one record per resource when P_SCHEDULING_LEVEL = 2. Each record receives a unique INTERFACE_ID drawn from the WIP_INTERFACE_S sequence and is stamped with P_GROUP_ID.
• LOAD_WIP — Validates and loads information from WIP_SCHEDULING_INTERFACE into the WIP tables for a given group.
• LOAD_WIP_CONCURRENT — The concurrent-program wrapper for LOAD_WIP. It checks for rows in WIP_SCHEDULING_INTERFACE matching the group with process_phase = 2 (validation) and process_status = 1 (pending). It returns a warning when no data qualify and an error when LOAD_WIP fails.
• VALIDATE_JOBS — Errors out interface records that do not correspond to existing jobs in status Unreleased, Released, Complete, or Hold.
• VALIDATE_SCHEDULING_LEVEL — Validates the scheduling level value on interface records.
• VALIDATE_DATES — Validates date information on interface records.
• VALIDATE_USAGE_RATE — Validates usage rate values.
• VALIDATE_OPS_RES_MATCH — Confirms that operations and resources match correctly.
• ERROR_ALL_IF_ANY — Marks the entire group as errored if any record within it fails validation.
• UPDATE_REQ_DATES — Updates requirement dates in the WIP scheduling structures.
• UPDATE_JOB_DATES — Updates job-level dates reflecting the loaded scheduling data.

Tables Accessed

WIP_SCHEDULING_INTERFACE is the primary staging and working table: LOAD_INTERFACE writes to it, and the validation and load procedures read from and update it. WIP_INTERFACE_S supplies the unique INTERFACE_ID values. WIP_DISCRETE_JOBS is referenced by VALIDATE_JOBS to confirm job existence and status, and by UPDATE_JOB_DATES. WIP_JOB_SCHEDULE_INTERFACE holds schedule-level interface data. WIP_OPERATIONS and WIP_OPERATION_RESOURCES hold the operation and resource detail that LOAD_WIP ultimately populates at scheduling level 1 and 2 respectively. WIP_REQUIREMENT_OPERATIONS is targeted by UPDATE_REQ_DATES. All are accessed through APPS synonyms.

Usage Notes

WIP_SCHEDULING is typically invoked in two modes. First, custom code or a supporting program calls LOAD_INTERFACE to stage scheduling rows into WIP_SCHEDULING_INTERFACE, keyed by an externally assigned group ID. Second, LOAD_WIP_CONCURRENT is submitted as an Oracle EBS concurrent program to validate the staged group and then apply it through LOAD_WIP. Because validation is gated on process_phase = 2 and process_status = 1, callers must ensure records are correctly phased before submission.

Because AUTHID CURRENT_USER applies, custom callers must hold appropriate privileges on the underlying objects. The package is best treated as a supported entry point for bulk scheduling operations; direct DML against the interface tables bypasses the validation logic implemented here, including the all-or-nothing behavior enforced by ERROR_ALL_IF_ANY.