Search Results crp_resource_plan_s

Overview

The APPS.CRP_PLANNER_PK package body implements the core Capacity Requirements Planning (CRP) engine within Oracle E-Business Suite. Its business function is to translate planned and discrete manufacturing demand into time-phased resource load requirements, allowing planners to compare available capacity against required capacity across work centers. The package drives the CRP concurrent programs that generate, refresh, and complete a capacity plan for one or more organizations. It operates on top of the Master Production Schedule and MRP output, consuming planned orders, recommendations, and work-in-process resource assignments, then persisting the resulting capacity picture into the resource plan tables. In EBS 12.1.1 and 12.2.2 the object resides in the APPS schema and is reported with VALID status. The ETRM metadata classifies the package under API classification OTHER, and it is not referenced by any other database object, indicating it is a top-level driver rather than a shared utility library. The name CRP_PLANNER_PK and the dependency list confirm integration with both the CRP resource-plan tables and the MRP planning engine.

Key Procedures and Functions

The ETRM metadata documents five procedures and functions within the package body:

• START_PLAN — Initializes the capacity planning process. It establishes the planning context for the requested plan and organization, typically clearing or preparing the target resource plan records and setting runtime state before detailed load calculations begin.
• COMPLETE_PLAN — Finalizes the planning run. It performs the closing steps after all resource loads have been computed, marking the plan as complete and making the resulting capacity data available for inquiry and reporting.
• PLAN_JOBS — Processes job-based (work order) supply to derive resource requirements. It evaluates discrete and repetitive job routings to determine the load each work center must absorb.
• PLAN_DISCRETE — Calculates capacity load originating from discrete manufacturing demand, converting discrete planned and released orders into resource requirements by work center and date bucket.
• PLAN_REPETITIVE — Calculates capacity load from repetitive manufacturing schedules, distributing repetitive production rates across routing resources and planning periods.

The complementary discrete, repetitive, and job routines allow the planner to load capacity from all three manufacturing execution styles supported by Oracle Manufacturing.

Tables Accessed

The documented dependency list identifies the tables this package reads and writes:

• CRP_RESOURCE_PLAN and CRP_RESOURCE_PLAN_S — the central capacity plan and its child resource-load detail, which hold the computed time-phased load per resource. These are the primary write targets; the user query "crp_resource_plan_s" corresponds to the detail table populated by this package.
• MRP_PLANS and MRP_PLAN_ORGANIZATIONS_V — supply the plan definition and the organizations in scope for the run.
• MRP_RECOMMENDATIONS and MRP_PLANNED_RESOURCE_REQS — provide planned-order and resource-requirement input generated by the MRP engine.
• MRP_SYSTEM_ITEMS and MRP_WIP_RESOURCES — supply item attributes and work-center resource definitions used to resolve load to specific resources.
• BOM_CALENDAR_DATES — provides the manufacturing calendar used to bucket and shift capacity requirements across valid working days.
• FND_PROFILE and MRP_PRINT_PK are referenced for profile-option retrieval and printing support respectively.

Usage Notes

CRP_PLANNER_PK is invoked indirectly by the standard Oracle Capacity planning concurrent programs rather than called directly from user forms. A planner defines a capacity plan, then launches the CRP planning program, which drives START_PLAN, dispatches the appropriate PLAN_JOBS, PLAN_DISCRETE, and PLAN_REPETITIVE routines according to the manufacturing environment, and concludes with COMPLETE_PLAN. Because the package writes to CRP_RESOURCE_PLAN and CRP_RESOURCE_PLAN_S, any custom extension should respect the same transaction boundaries and validity rules. It is not referenced by other database objects, so it is safe to treat as an entry-point driver. Custom code that needs capacity results should query CRP_RESOURCE_PLAN_S after the concurrent process completes rather than call the package procedures directly, preserving data integrity and the intended planning workflow.