Search Results wip_add




Overview
Explore in AI Chat

Overview

WIP_JOB_DETAILS is an Oracle Work in Process (WIP) PL/SQL package owned by the APPS schema, delivered as part of the EBS 12.1.1 and 12.2.2 code lines. It exists to move discrete job detail data between the WIP open interface staging tables and the core WIP execution tables. The package header is declared with AUTHID CURRENT_USER and exposes a small, tightly scoped API consisting of two documented procedures, supported by a set of package level constants that classify the interface record types and the DML operation being requested.

The constants define the semantic vocabulary of the load: WIP_DELETE, WIP_ADD and WIP_CHANGE capture the requested action, while WIP_RESOURCE, WIP_MTL_REQUIREMENT, WIP_OPERATION, WIP_RES_USAGE, WIP_SUB_RES, WIP_OP_LINK, WIP_SERIAL, WIP_RES_INSTANCE and WIP_RES_INSTANCE_USAGE identify the detail entity type. This structure indicates the package acts as the transformation and validation engine behind the Discrete Job open interface, converting staged interface rows into fully formed job, operation, resource and material records.

Key Procedures and Functions

  • LOAD_ALL_DETAILS — the primary driver procedure. It accepts a group identifier and a parent header identifier together with a standard-alone indicator, and returns the conventional EBS out parameters for error code, error message and return status. It processes every staged detail row associated with the supplied group and parent header, applying the appropriate create, update or delete logic based on the constants described above.
  • DEFAULT_WIP_ENTITY_ID — the procedure surfaced by the user's search term. It accepts the same group identifier and parent header identifier and returns the same error code, error message and return status triple. Its role is to resolve and assign the WIP entity identifier for staged interface records that lack one, ensuring that dependent detail rows are correctly associated with the parent job entity before the load proceeds.

Tables Accessed

The package reads from and writes to four documented tables, all referenced through APPS synonyms:

  • WIP_JOB_DTLS_INTERFACE — the staging table holding inbound job detail rows awaiting validation and transfer.
  • WIP_JOB_SCHEDULE_INTERFACE — the staging table for job scheduling information consumed alongside the detail rows.
  • WIP_OPERATIONS — the core execution table receiving validated operation records.
  • WIP_OPERATION_RESOURCES — the core execution table receiving validated resource assignments for those operations.

The interface tables supply the source data; the core tables are the targets of the load and are the reason the entity identifier must be defaulted correctly before detail processing begins.

Usage Notes

WIP_JOB_DETAILS is not intended for direct end user invocation. It is normally called by the Discrete Job open interface processing logic, where a loader calls DEFAULT_WIP_ENTITY_ID first to establish entity context and then LOAD_ALL_DETAILS to process the group. Because it is referenced by nineteen other packages, it functions as a shared internal utility rather than a standalone entry point.

Custom integrations that populate the WIP interface tables may invoke the package directly from custom PL/SQL, but they must supply valid group and parent header identifiers and must inspect the returned error code, error message and return status. Direct calls should respect the AUTHID CURRENT_USER declaration and the package's dependence on the WIP interface and execution tables.