Search Results node_level_id

Overview

APPS.CSP_MIN_MAX_PLANNING is a PL/SQL package in Oracle E-Business Suite that supports the min-max planning functionality within the Enterprise Planning and Manufacturing (CSP) module. Although the ETRM metadata classifies the API type as "OTHER," the package name and its procedures clearly indicate a role in the min-max replenishment planning process, where minimum and maximum inventory thresholds drive replenishment recommendations. The package is defined with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, which is consistent with Oracle EBS conventions for packages that operate within the security context of the calling application or concurrent program. The header comment ($Header: cspppmms.pls 120.0 2005/05/25) indicates this is a long-standing, stable component of the EBS codebase, unchanged since release 11i-era development and carried forward into 12.1.1 and 12.2.2. Its primary business function is to determine which items, at a given organization and planning level, fall below minimum or above maximum stock thresholds and to generate the resulting replenishment plan.

Key Procedures and Functions

• NODE_LEVEL_ID (procedure and function overloads) — This overloaded pair of subprograms manages a package-level identifier for the planning node or level. One variant accepts a p_level_id VARCHAR2 parameter and stores or sets the internal level identifier; the second is a no-argument function that returns the currently stored level identifier. This mechanism allows the min-max planning logic to retain context about which node in the organization or item hierarchy is being processed across successive procedure calls within a session.
• RUN_MIN_MAX — The principal driver procedure of the package. It accepts the standard concurrent program output parameters, errbuf and retcode, indicating that it is designed to be invoked as a concurrent program. It also accepts a broad set of input parameters covering organizational context (p_org_id), planning level selection, subinventory filtering, category and item range selections, planner and buyer ranges, sorting and cutoff options, user identification, restock settings, replenishment item handling, and a series of netting and inclusion flags (net un-reserved, reserved, WIP, purchase orders, manufacturing orders, WIP jobs, internal requisitions, and non-nettable supply). Additional flags govern lot control, display mode, description display, and purchasing revision handling. Collectively, these parameters allow RUN_MIN_MAX to reproduce the full set of user selections available on the min-max planning report submission form.

Tables Accessed

The package references several tables via APPS synonyms, reflecting its integration with inventory, planning, and customer data:

• MTL_SECONDARY_INVENTORIES — Supplies subinventory definitions used when subinventory-level planning is enabled.
• CSP_PLANNING_PARAMETERS — Stores and retrieves planning configuration and default parameter values.
• CSP_SEC_INVENTORIES — Provides subinventory data within the Enterprise Planning schema.
• CSP_RS_CUST_RELATIONS and HZ_CUST_ACCT_SITES / HZ_CUST_SITE_USES — Support customer relationship and site information, relevant where min-max planning interacts with customer-related supply or demand.
• PO_LOCATION_ASSOCIATIONS — Links purchasing locations used in the replenishment planning logic.
• HR_ALL_ORGANIZATION_UNITS — Resolves organization names and identifiers for the planning run.
• FND_CONCURRENT_PROGRAMS / FND_CONCURRENT_REQUESTS — Support concurrent program invocation and status reporting.
• DBMS_LOCK — Used to serialize concurrent planning runs and prevent conflicting executions.

Usage Notes

RUN_MIN_MAX is structured for concurrent program invocation, as evidenced by its errbuf and retcode output parameters and its reference to FND_CONCURRENT_PROGRAMS and FND_CONCURRENT_REQUESTS. The standard invocation path is through the min-max planning report or planning form in the Enterprise Planning application, where the user selects an organization, planning level, and optional category, item, planner, and buyer ranges before submitting the concurrent request. The extensive inclusion flags allow users to control which supply and demand sources (purchase orders, manufacturing orders, WIP, internal requisitions, reserved and unreserved balances, non-nettable inventory) are considered during netting. The NODE_LEVEL_ID procedure and function support programmatic control of planning context, so custom code or form logic can set the level before calling RUN_MIN_MAX directly. Because the API is classified as OTHER rather than a public or private API, it should be treated as an internal EBS component; customizations should avoid direct modification and instead rely on supported extension mechanisms. The use of DBMS_LOCK indicates the package itself manages locking to prevent overlapping planning runs, so callers should not assume they need to add their own serialization. As with any long-standing EBS package, behavior is consistent across 12.1.1 and 12.2.2, though the 12.2 online patching model means concurrent request records are managed through the patching-aware FND tables.