R12.2.9 Oracle Advanced Supply Chain Planning Fundamentals — Lesson 3: Planner Workbench, Exceptions, Pegging, and Simulation

Technical Scope

• plan launch, status, memory use, run diagnostics, and output verification
• planner workbench, supply/demand views, pegging, actions, and firming
• exceptions, priorities, late orders, shortages, overloads, and root-cause navigation
• what-if changes, simulations, comparison, release recommendations, and decision logs

Instructor Demonstration

The instructor diagnoses plan launch, status, memory use, run diagnostics, and output verification, then connects it to planner workbench, supply/demand views, pegging, actions, and firming. The demonstration captures the exact configuration, transaction, command, query, log, or screen evidence needed to prove intended behavior and the applicable control boundary.

Applied Workshop

Learners build and verify an implementation covering planner workbench, supply/demand views, pegging, actions, and firming and exceptions, priorities, late orders, shortages, overloads, and root-cause navigation. The exercise introduces a realistic exception related to what-if changes, simulations, comparison, release recommendations, and decision logs and requires a reversible correction supported by before-and-after evidence.

1. Confirm scope, identities, data, dependencies, controls, and expected result.
2. Perform the product-specific configuration or analysis and record exact steps.
3. Validate functional behavior, security, data integrity, and operational observability.
4. Introduce the defined failure condition, diagnose the cause, and apply a safe correction.
5. Document rollback, acceptance evidence, unresolved risk, and ownership.

Validation Standard

Acceptance requires accurate handling of exceptions, priorities, late orders, shortages, overloads, and root-cause navigation, traceable proof for plan launch, status, memory use, run diagnostics, and output verification, and a repeatable recovery path for what-if changes, simulations, comparison, release recommendations, and decision logs. Results must be understandable to both implementers and operational support teams.

Failure Analysis

Learners compare symptoms, logs, state, dependencies, and recent changes when what-if changes, simulations, comparison, release recommendations, and decision logs occurs. The final diagnosis must separate the immediate fix from the preventive control.

Practical Outcome

The completed output is a tested planner workbench, exceptions, pegging, and simulation implementation or analysis, with validation evidence, troubleshooting notes, rollback guidance, and a concise operational handover.