Search Results wip_wictpg




Overview
Explore in AI Chat

Overview

WIP_WICTPG is an Oracle Work in Process (WIP) purge utility package owned by the APPS schema. Its name derives from the WIP "Work In Process purge" functional area, and the package serves as the procedural engine behind the WIP discrete job purge process in Oracle E-Business Suite releases 12.1.1 and 12.2.2. When a discrete job, repetitive schedule, or flow schedule is no longer needed, Oracle EBS does not immediately remove it from the transactional tables. Instead, the purge process must reconcile and clean up the associated material transactions, move orders, demand and supply records, serial number associations, and attachment references before the source entities can be removed. WIP_WICTPG encapsulates this cleanup logic.

The package is classified in the ETRM as API type OTHER and carries a VALID status in the APPS schema. It is not a public, customer-callable business API in the same sense as the WIP job creation or move transaction APIs; rather, it is an internal implementation package whose single documented entry point, PURGE, is invoked by Oracle's seeded purge infrastructure — notably the WIP purge concurrent program and the Enterprise Command Center XML publisher package WIP_WIPPURGE_XMLP_PKG. The 12.2.2 metadata confirms two dependent packages reference WIP_WICTPG, and the 12.1.1 dependency listing shows additional inbound references from WSM_JOBPURGE_GRP, the Oracle Warehouse Management job purge request set.

Key Procedures and Functions

The ETRM documentation records exactly one public procedure or function within WIP_WICTPG:

  • PURGE — The primary cleanup routine. It coordinates the removal of WIP purge staging data and the dependent transactional records that block deletion of a discrete job or schedule. It reads candidate entities from the WIP purge temporary table, resolves their related lines and entity records, and drives the purge of associated material transaction, demand, supply, serial number, and attachment data. Because the ETRM does not publish the formal signature, the parameter list must not be assumed; callers should treat PURGE as an internal routine invoked through the seeded purge concurrent programs rather than from custom code.

Tables Accessed

WIP_WICTPG reads and writes a broad set of base tables through APPS synonyms. Documented core WIP tables include WIP_ENTITIES (the discrete job and schedule header), WIP_LINES (job operation and material requirement lines), and WIP_PURGE_TEMP, the staging table that holds the set of entities selected for purging. Costing tables — CST_PERIOD_VALUE_TEMP, CST_STD_COST_ADJ_DEBUG, and CST_STD_COST_ADJ_VALUES — support removal or adjustment of cost records tied to purged jobs.

Transaction and supply/demand tables include MTL_MATERIAL_TRANSACTIONS, MTL_MATERIAL_TRANSACTIONS_TEMP, MTL_MATERIAL_TXN_ALLOCATIONS, MTL_SERIAL_NUMBERS, MTL_DEMAND, MTL_DEMAND_INTERFACE, MTL_SUPPLY_DEMAND_TEMP, and MRP_RELIEF_INTERFACE. These are accessed to clear the material movements, allocations, serial associations, planning demand, and MRP relief records generated by the job being purged. FND_ATTACHED_DOCUMENTS is referenced to remove or detach documents attached to the purged entities. The presence of TEMP and INTERFACE tables indicates that the package coordinates staged deletion rather than issuing simple direct deletes.

Usage Notes

WIP_WICTPG is normally invoked indirectly. In a standard EBS implementation, users submit the WIP purge concurrent program, which populates WIP_PURGE_TEMP and calls PURGE to perform the physical cleanup. The XML publisher package WIP_WIPPURGE_XMLP_PKG and the WSM job purge group both call into WIP_WICTPG, so the routine may execute from WIP, WSM/WMS, and command-center driven purge flows. Direct invocation from custom PL/SQL is discouraged because the interface is undocumented and the package depends on session and concurrent-program context established by the seeded programs. When customizing or troubleshooting a purge that leaves residual rows, DBAs should inspect the package body via the ETRM "show dependent code" link and validate behavior on a cloned instance, since the package is proprietary Oracle code and is not supported as a public API.