Search Results copy_to_wjsi

Overview

WSMPJITH is an Oracle E-Business Suite PL/SQL package owned by the APPS schema. It belongs to the Work in Process (WIP) and shop floor manufacturing family of APIs and is classified in the ETRM repository under the generic API classification of "OTHER." The package header is defined with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking user rather than the defining user, which is consistent with the standard Oracle EBS convention for packages that are called from forms, concurrent programs, and other PL/SQL units.

Functionally, WSMPJITH supports the movement of job and schedule data between the WIP job scheduling structures and the Work in Process job schedule interface tables exposed through the WSM (Workflow and Scheduling Management / shop floor) schema. The two documented procedures, COPY_TO_WJSI and DELETE_FROM_WJSI, operate as a pair: the first copies records into the interface, and the second removes them once processing is complete or an error is detected. This copy-and-delete pattern is common where an external or scheduling-driven process needs to stage WIP job schedule information before it is validated and consumed by other WIP processing.

Key Procedures and Functions

The ETRM metadata documents two procedures on the package specification.

• COPY_TO_WJSI — Populates the WIP job schedule interface with data for a given job or schedule context. It returns an interface group identifier along with standard error code and error message out parameters, allowing the calling program to track the batch of rows it inserted and to detect failures without raising exceptions. The OUT group identifier is the key handle used by subsequent processing to locate the inserted records.
• DELETE_FROM_WJSI — Removes records previously staged through the copy procedure, keyed by the interface group identifier. It also returns error code and error message out parameters. This procedure supports cleanup of the interface after the staged rows have been processed, preventing stale data from accumulating in the interface tables.

Both procedures follow the Oracle EBS API convention of returning status through x_err_code and x_err_msg out parameters rather than propagating exceptions, so callers are expected to inspect these values after each invocation.

Tables Accessed

The procedures reference the following tables through APPS synonyms:

• WIP_JOB_SCHEDULE_INTERFACE and WIP_JOB_SCHEDULE_INTERFACE_S — the primary interface tables into which job schedule rows are copied and from which they are deleted. The _S variant is the sequence-backed table used to generate interface identifiers.
• WSM_LOT_JOB_INTERFACE — the shop floor lot and job interface table, used alongside the WIP interface tables to stage job and lot information for scheduling processing.
• WIP_ENTITIES_S — the sequence source for WIP entity identifiers, supporting generation of keys for the staged records.
• WIP_INTERFACE_ERRORS — the standard WIP interface error repository, used to record validation failures encountered while staging or processing interface rows.
• DUAL — used for scalar evaluations and sequence lookups.

Usage Notes

WSMPJITH is an internal, low-level package rather than a public, documented integration API. It is not referenced by any other documented package in the ETRM repository, which indicates that its callers are most likely Oracle forms, concurrent programs, or scheduling-related code delivered within the WIP and WSM modules rather than customer-facing APIs.

Because the package depends on interface tables that are shared with standard WIP job scheduling processing, it should not be invoked concurrently with the standard WIP interface manager without careful coordination. The AUTHID CURRENT_USER declaration means the caller must have the appropriate privileges on the underlying WIP and WSM objects. For custom development, direct calls to COPY_TO_WJSI and DELETE_FROM_WJSI are generally discouraged in favor of supported WIP job and schedule APIs; where direct use is required, callers should always check x_err_code and x_err_msg and delete the staged group on failure to avoid leaving orphaned interface rows.