Search Results populate_who

Overview

WIP_PERF_TO_PLAN is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It is classified under the ETRM as an "OTHER" API, meaning it is not a formally published open interface but is instead an internal utility package used by Oracle Work in Process (WIP) to populate and maintain performance-to-plan information for discrete jobs, repetitive schedules, and flow schedules. The package consolidates shop floor execution data — material transactions, item costs, and schedule quantities — into the WIP_BIS_PERF_TO_PLAN business intelligence table so that planners and production supervisors can compare actual production against planned production over a given date range. The header declares AUTHID CURRENT_USER, so procedures execute with the privileges of the calling schema, which is consistent with the package's role as a scheduled batch utility rather than a tightly controlled public interface.

Key Procedures and Functions

The package exposes six documented procedures that together form an extract-transform-load sequence for performance data:

• Load_Performance_Info — The primary entry point, accepting a date-from and date-to range along with the standard concurrent program OUT parameters (errbuf, retcode). It orchestrates the overall load.
• Populate_Performance — Gathers planned and actual production performance for the given date range. It accepts date parameters, the calling user ID and application ID for auditing, and returns error message and error number OUT parameters.
• Populate_Who — Populates the "WHO" audit columns (created_by, creation_date, last_updated_by, last_update_date and related attributes) on the performance records. This is the procedure users typically reach when searching for "populate_who." It accepts date-from, date-to, user ID, and application ID inputs, with error message and error number outputs.
• Update_Actual_Quantity — Refreshes actual completed or transaction quantities on the performance records, returning error message and error number.
• Post_Populate_Perf_Info — Performs post-processing and any required derivations or validations after the main population step, returning error number and error message.
• Clean_Up_Exception — Removes or resolves exception rows left by failed or partial loads. It takes no parameters.

All error reporting follows the standard EBS concurrent manager convention of paired error number and error message OUT parameters.

Tables Accessed

ETRM documentation identifies the following tables referenced through APPS synonyms:

• WIP_BIS_PERF_TO_PLAN — The target staging/target table that stores performance-to-plan rows; written by Populate_Performance and Populate_Who.
• WIP_DISCRETE_JOBS, WIP_REPETITIVE_SCHEDULES, WIP_FLOW_SCHEDULES — Source schedules supplying planned quantities; differing by manufacturing method.
• WIP_ENTITIES — The common WIP entity table linking jobs and schedules, used to resolve entity identifiers.
• MTL_MATERIAL_TRANSACTIONS and MTL_MATERIAL_TXN_ALLOCATIONS — Transaction history and allocation detail used to derive actual issued and completed quantities.
• CST_ITEM_COSTS — Item cost information, used to value production for performance reporting.
• MTL_PARAMETERS — Organization-level manufacturing parameters controlling defaults and validation.

Usage Notes

WIP_PERF_TO_PLAN is normally invoked by a concurrent program (the performance-to-plan load) submitted from the Work in Process responsibility or by a scheduled request set. It is not referenced by any other documented package, confirming that it is a top-level batch utility rather than a shared library. Custom code should call Load_Performance_Info rather than invoking lower-level procedures directly, since it sequences the populate, update, post-populate, and cleanup steps in the intended order. Because Populate_Who persists WHO audit columns from the supplied user and application IDs, callers must pass valid FND_USER and FND_APPLICATION identifiers to avoid audit integrity issues. Given the 2002 header date, the package is stable and unchanged across 12.1.1 and 12.2.2 in functional terms; the 12.2 online patching model does not alter its behavior since it holds no editioned database objects requiring special handling.