Search Results mrp_planner_status

Overview

APPS.MRP_PLANNER_TASKS_V is a reporting view in Oracle E-Business Suite that exposes the execution history of the Material Requirements Planning (MRP) planner. It presents one row per planner task run — for example a plan generation, a plan compile, or a planning manager batch — together with the task's status, timing, and resource consumption. Rather than querying the underlying MRP_PLANNER_TASKS table directly, the view joins to MFG_LOOKUPS so that the raw status code stored on the task row is translated into a user-readable meaning. This makes the view the natural access point for both ad-hoc reporting and external integration, since consumers receive a decoded status value without needing to resolve the MRP_PLANNER_STATUS lookup themselves.

The view is owned by APPS and is documented for both Oracle EBS 12.1.1 and 12.2.2. It is read-only and carries no application logic beyond the lookup resolution and the formatting of elapsed time, so it is safe to use in reports, concurrent-program extracts, and downstream interfaces.

Underlying Base Objects

The view is defined over two referenced objects: MFG_LOOKUPS (a view) and MRP_PLANNER_TASKS (a synonym). MRP_PLANNER_TASKS is the driver, holding the actual planner task records keyed by organization, plan level, compile designator, and request. MFG_LOOKUPS supplies the descriptive text for the status code. The two are joined on the condition that the lookup type equals 'MRP_PLANNER_STATUS' and the lookup code equals the task's STATUS value.

Because the join is an inner join, a planner task whose status code has no matching, active row in the MRP_PLANNER_STATUS lookup set will not appear in the view. This is the single most important behavioral characteristic of MRP_PLANNER_TASKS_V and explains the common user question behind the search term mrp_planner_status: the view and the lookup are inseparable, and the lookup is what determines which rows are visible and what text is displayed.

Key Columns

• ORGANIZATION_ID — the inventory organization against which the planner task executed.
• COMPILE_DESIGNATOR — the plan identifier the task acted upon, such as a named plan.
• REQUEST_ID — the concurrent request that spawned or is associated with the task, allowing correlation with the standard concurrent manager reports.
• PLAN_LEVEL — indicates the planning level of the run (for example, plan-level versus organization-level processing).
• MEANING — the decoded status text derived from the MRP_PLANNER_STATUS lookup, replacing the numeric status code.
• BATCH_NUMBER — the batch grouping under which the task was submitted.
• START_DATE / END_DATE — the timestamps for the beginning and completion of the task, forming the basis of all duration calculations.
• PROCESSING_SECONDS (formatted) — the total processing time expressed as HH:MI:SS using LPAD and TRUNC/MOD arithmetic on the stored processing seconds.
• Elapsed/wait time (formatted) — the difference between wall-clock elapsed time (derived from END_DATE - START_DATE) and actual processing seconds, also rendered as HH:MI:SS. A GREATEST(...,0) guard prevents negative values when processing exceeds elapsed time.

Common Use Cases and Queries

The view is most often used to monitor plan run history, diagnose long-running or failed planner tasks, and report planner throughput by organization and plan. A typical query retrieves recent task executions ordered by start time:

• SELECT organization_id, compile_designator, request_id, plan_level, meaning, batch_number, start_date, end_date FROM apps.mrp_planner_tasks_v WHERE organization_id = :org ORDER BY start_date DESC;
• To find currently active or failed runs, filter on the decoded status text: SELECT compile_designator, meaning, start_date FROM apps.mrp_planner_tasks_v WHERE meaning IN ('Running','Failed') ORDER BY start_date;
• To measure processing efficiency, select request_id alongside the formatted processing and elapsed columns and join REQUEST_ID to FND_CONCURRENT_REQUESTS for the submitting user and program name.

Because status text is sourced from a lookup meaning, any customization of the MRP_PLANNER_STATUS lookup set directly affects both the values returned and which task rows are surfaced. Report authors should therefore treat the MEANING column as configuration-dependent and, where stable codes are required for automation, prefer joining back to MRP_PLANNER_TASKS.STATUS directly.