Search Results load_sub_types




Overview
Explore in AI Chat

Overview

The APPS.WIP_JOB_DTLS_VALIDATIONS package is a server-side PL/SQL validation library within Oracle Work in Process (WIP). Its business function is to enforce integrity and business-rule checks on job detail records before those records are processed into actual discrete jobs. The package is declared with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking user rather than the package owner, and it operates against the WIP job detail interface. The header comment ($Header: wipjdvds.pls 115.8 ...) and the documented structure indicate that it is an internal validation engine used to inspect a logical group of interface rows associated with a discrete job, either before or during an import or update operation.

In practice, the package validates three broad categories of data: the parent job itself (existence, status, and firmness), the per-operation and per-substitution detail rows (sequence and type validity), and the audit columns (creator and last updater). A distinguishing feature is its supporting role in the WIP Job Details interface, where data loaded from external systems or custom sources must satisfy all constraints before being applied to the production job tables.

Key Procedures and Functions

Eight documented procedures make up the package:

  • JOBS — Verifies that the jobs referenced by a given interface group must exist; it is the foundational existence check for parent job records.
  • JOB_STATUS — Enforces that each job is in one of the permissible statuses: unreleased, released, complete, or hold.
  • IS_FIRM — Ensures that a job under validation is not firmed; firmed jobs are excluded from this processing path.
  • OP_SEQ_NUM — Confirms that an operation sequence number supplied against a job detail actually exists within that job's operations.
  • LOAD_SUB_TYPES — Validates that the load type is 1 (resource) or 2 (requirement) and that the substitution type is 1 (delete), 2 (add), or 3 (delete), constraining the allowable detail actions.
  • LAST_UPDATED_BY — Confirms the last-updated user is a valid, recognized user in the application.
  • CREATED_BY — Confirms the creating user is a valid, recognized user in the application.
  • ERROR_ALL_IF_ANY — A utility that implements an all-or-nothing error policy: if any row for a discrete job fails validation, all rows for that job are flagged as failed, preventing partial and inconsistent imports.

Parameter lists are intentionally not restated here; the documentation confirms procedural names and purposes only.

Tables Accessed

The package reads and writes the following documented tables through APPS synonyms:

  • WIP_DISCRETE_JOBS — The primary discrete job record, consulted for job existence, status, and firmness checks and used to cross-reference the parent job for each detail row.
  • WIP_JOB_DTLS_INTERFACE — The interface table holding job detail rows (load/substitution types and audit columns) pending validation and import.
  • WIP_JOB_SCHEDULE_INTERFACE — The interface table for job schedule information, validated alongside the detail rows for scheduling-related constraints.
  • WIP_OPERATIONS — Used by OP_SEQ_NUM to confirm that the supplied operation sequence number exists within the job.

These accesses support both the validation predicates and the error-marking logic, with ERROR_ALL_IF_ANY updating the interface rows' error status.

Usage Notes

This package is an internal validation utility rather than a public API. It is typically invoked indirectly by the WIP Job Details import or update process — for example, from a concurrent program or from the forms-driven interface that loads WIP_JOB_DTLS_INTERFACE rows — and it is referenced by one other package per the ETRM metadata. Because the procedures operate on group identifiers and job identifiers, callers should populate and validate a complete group of interface rows for a job in a single invocation. The documented policy in ERROR_ALL_IF_ANY means that custom code invoking these validations should expect every row of a failing job to be marked in error, not merely the offending row. When extending or troubleshooting imports, confirm that jobs are unfirmed and in a permitted status before the validation routines are called, as those are prerequisite conditions enforced by JOB_STATUS and IS_FIRM.