Search Results mrp_planner_tasks




Overview

MRP_PLANNER_TASKS is a table in the MRP schema of Oracle E-Business Suite, owned by the Master Scheduling/MRP product family. It stores planner task information generated during MRP, MPS, and DRP planning runs in EBS 12.1.1 and 12.2.2. Each planning run submits concurrent requests, and this table records the state, timing, and outcome of those tasks at each plan level of the planning process. It functions as an operational log of planner activity, tracking how long each processing step took, when batches began and ended, and whether the task completed successfully. This information supports diagnostics, performance tuning, and restart or recovery of planning runs.

From a Data Vault modeling perspective, the metadata classifies this object heuristically as standalone. Under that classification it is best modeled as a satellite-like table containing descriptive attributes keyed by a composite business key, without a hub or link association to other documented parent entities. The classification is heuristic and should be confirmed against actual foreign-key constraints before designing downstream integrations.

Key Information Stored

The documented physical schema contains fifteen columns. The primary key, MRP_PLANNER_TASKS_PK, is a composite key consisting of REQUEST_ID, PLAN_LEVEL, and STATUS. A unique index, MRP_PLANNER_TASKS_U1, covers the same three columns and serves as the business-key candidate. Notable columns include:

  • REQUEST_ID — Identifier of the concurrent request under which the planner task executed; the principal link to the concurrent manager request history.
  • PLAN_LEVEL — The planning level (for example, plan-level processing stage) at which the task ran.
  • STATUS — The task's current status, indicating completion or failure state.
  • COMPILE_DESIGNATOR — The plan or compilation identifier to which the task belongs.
  • ORGANIZATION_ID — The inventory organization context for the planning run.
  • BATCH_NUMBER — The batch sequence associated with the task, used to group related processing units.
  • START_DATE and END_DATE — The timestamps marking when the task began and finished.
  • BATCH_START_DATE — The start timestamp for the batch containing the task.
  • PROCESSING_SECONDS — Elapsed processing time for the task, supporting performance analysis.

The remaining columns are the standard EBS audit columns: LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The table is typically queried to monitor plan-run performance, identify long-running plan levels, and audit failed tasks. A representative query joins it to the concurrent request interface:

  • Select tasks with high PROCESSING_SECONDS to isolate performance bottlenecks by PLAN_LEVEL and BATCH_NUMBER.
  • Filter by REQUEST_ID to review all tasks belonging to a single planning run.
  • Group by COMPILE_DESIGNATOR and ORGANIZATION_ID to compare planning across organizations or plans.
  • Compare START_DATE and END_DATE with BATCH_START_DATE to measure batch overlap and contention.
  • Report on STATUS distribution to detect recurring failures.

Example SQL pattern:

  • SELECT request_id, plan_level, status, processing_seconds FROM mrp.mrp_planner_tasks WHERE request_id = :req ORDER BY plan_level, batch_number;
  • SELECT plan_level, AVG(processing_seconds) avg_sec FROM mrp.mrp_planner_tasks GROUP BY plan_level;

Related Objects

Although the mined relationship model classifies the table as standalone, its columns relate to standard EBS objects used in planning and concurrent processing:

These joins allow administrators to correlate task execution with the concurrent request lifecycle and plan configuration for complete operational reporting.