Search Results purge_details

Overview

APPS.MSC_PHUB_CUSTOM_PKG is a customization extension package body within the Advanced Supply Chain Planning (ASCP) module of Oracle E-Business Suite, specifically part of the MSC (Master Scheduling/Collaborative Planning) schema family. It is delivered as an intentionally empty stub that customers extend to manage custom planning measures and custom planning data alongside the standard ASCP planning engine. The package is tied to the MSC_PHUB (Planning Hub) infrastructure, which governs the archival, population and purging of planning data across plan runs.

The package exposes two extension points: POPULATE_DETAILS, which archives custom measure data for a specific plan and plan run, and PURGE_DETAILS, which removes that custom data when plan runs are purged. Because the shipped source contains only logging calls plus placeholder comments, the body serves as a template — the actual archival and cleanup logic must be implemented by the customer. The package is classified as OTHER rather than a formal public API, confirming it is a customization hook rather than a supported functional interface.

The package depends on MSC_PHUB_UTIL for logging, indicating it operates inside the Planning Hub processing framework and is expected to participate in the same transactional and error-handling conventions used by the seeded PHUB routines.

Key Procedures and Functions

• POPULATE_DETAILS — Archives custom measures for a given plan and plan run. It receives a plan identifier and a plan run identifier and is intended to contain customer-written logic that copies or stages custom measure values into archival structures. The seeded implementation resolves the parameters, logs the invocation, and returns without action; developers are instructed to populate custom codes within the body and to set the return code to -1 in the event of an error.
• PURGE_DETAILS — Purges custom measures for a given plan name and plan run identifier. Its contract supports two modes: when a plan run identifier is supplied, only that run's archived custom data is removed; when the plan run identifier is null, all archived versions for the named plan are purged. As with POPULATE_DETAILS, the delivered body only logs the call and leaves the deletion logic to be supplied by the implementer.

Tables Accessed

The documented metadata does not enumerate any base tables referenced through APPS synonyms. This is consistent with the stub nature of the package: the shipped body contains no DML or queries. Any tables read or written by this package are therefore customer-defined or customer-selected, and are expected to be custom archive tables created to hold the custom measures processed by POPULATE_DETAILS and removed by PURGE_DETAILS. Implementers should follow ASCP archival naming conventions and ensure that custom purge logic respects the plan-run granularity described in the procedure contract, including the null plan run identifier case that triggers a full-plan purge.

Usage Notes

MSC_PHUB_CUSTOM_PKG is invoked by the Planning Hub framework rather than being called directly by end users. The metadata records that the package is referenced by one other package, meaning a seeded PHUB routine calls into these procedures as part of the standard plan archival and plan purge lifecycle. Typical triggers include the ASCP plan archival concurrent process and the purge/cleanup process for obsolete plan runs, both of which execute POPULATE_DETAILS and PURGE_DETAILS respectively so that custom data stays synchronized with seeded planning data.

Because the delivered procedures are empty, planners will observe no custom behavior until the customer implements the bodies. When extending the package, developers should preserve the existing logging calls, honor the documented error contract by setting retcode to -1 on failure, and apply the same upgrade-safe practices used for other ASCP custom hooks. In EBS 12.1.1 and 12.2.2, the file is identified by the header MSCHBCUB.pls, version 120.0.12020000.2, so online patching in 12.2.x may require reapplying customer code after any patch that replaces the stub.