Search Results wip_osp




Overview
Explore in AI Chat

Overview

WIP_OSP is a PL/SQL package in the APPS schema that supports Outside Processing (OSP) within Oracle Work in Process. Outside processing is the practice of routing discrete jobs, repetitive schedules, or EAM work orders to an external supplier for one or more operations, and the associated functionality to automatically generate and manage the purchasing documents that support that supplier relationship. The package is a core dependency of the OSP workflow: it validates whether an operation can be released to a supplier, creates requisitions from which purchase orders are subsequently derived, and synchronizes purchase requisition or purchase order quantities with the manufacturing schedule as quantities change.

The object is classified as OTHER (not a published public API) in the ETRM 12.2.2 metadata, indicating it is an internally consumed package rather than a formally supported extension point. It is marked VALID and is referenced by 23 other packages, including WIP_CHANGE_STATUS, WIP_JOBCLOSE_PRIV, WIP_MOVPROC_PRIV, WIP_REPETITIVE_UTILITIES, WIP_MASSLOAD_PUB, and several EAM and WSM packages, confirming its central role in both discrete and enterprise asset management outside processing flows.

Key Procedures and Functions

  • RELEASE_VALIDATION — Determines whether an outside processing operation may be released for supplier performance.
  • CREATE_REQUISITION — Creates a purchasing requisition line for an outside processing operation, supporting the initial requisition generation step.
  • CREATE_ADDITIONAL_REQ — Creates an incremental requisition when additional OSP quantity must be sourced beyond what was previously requested.
  • PO_REQ_EXISTS — Checks whether a requisition already exists for the relevant operation or schedule, preventing duplicate requisition creation.
  • PO_REQ_CREATED — Confirms or records that a requisition has been generated.
  • CONVERTTOPRIMARYMOVEQTY — Converts a move quantity into the primary quantity, aligning OSP requisition quantities with the job or schedule UOM.
  • IS_ORDER_OPEN — Tests whether the associated purchase order remains open for further processing.
  • ARE_QA_PLANS_AVAILABLE — Determines whether quality assurance plans are defined, affecting inspection handling on OSP receipts.
  • CHECKOSP — General validation routine verifying OSP eligibility and configuration for a given context.
  • UPDATEPOREQNBD — Updates the purchase requisition need-by date.
  • UPDATEPOREQNBDMANAGER — Updates the requisition need-by date using planner or manager defaults, typically driven by lead time calculations.
  • UPDATEPOREQQUANTITY — Synchronizes requisition quantity with changes to the job or schedule quantity.
  • CANCELPOREQ — Cancels the purchase requisition associated with an OSP operation when the work order or schedule is cancelled or the operation is removed.
  • IS_BACK_TO_BACK_OSP — Identifies whether the OSP arrangement is a back-to-back flow, where the purchase order is linked directly to a sales order or customer demand.

Tables Accessed

Purchasing tables dominate the package's data access. PO_REQUISITIONS_INTERFACE_ALL is used to stage requisitions for import, while PO_DISTRIBUTIONS_ALL, PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, PO_RELEASES_ALL, and PO_LINE_TYPES support validation and synchronization of the resulting purchase documents. Manufacturing and inventory objects include MTL_SYSTEM_ITEMS, MTL_PARAMETERS, and MTL_UNITS_OF_MEASURE for item and UOM validation. Routing and resource data come from BOM_DEPARTMENTS, BOM_RESOURCES, and BOM_CALENDAR_DATES. HR_ORGANIZATION_INFORMATION and FND_USER supply organization and user context, including manager identification for need-by date updates.

Usage Notes

WIP_OSP is not a documented public API and should not generally be called directly from custom code. It is invoked internally by the OSP Workbench (WIP_ICX_OSP_WORKBENCH_V), move transactions, job close, and mass load processing, as well as EAM work order release and status change routines. Customizations extending OSP behavior should prefer supported public APIs where available and treat WIP_OSP strictly as internal packaged logic. Any direct invocation requires careful regression testing, because the package is referenced by 23 dependent packages and a signature or behavioral change could affect the entire OSP flow across WIP, EAM, and WSM modules.