Skip to main content

​
Overview

A scenario is one run of the optimizer against a planning model. The model is the reusable setup: horizon, resources, BOMs, tags, and solver behavior. The scenario is where you supply the inputs the plan will actually see: the start date, demand, supply, on-hand inventory, inventory goals, and resource capacity for this specific horizon. Every scenario is saved. You can re-open it, inspect its inputs and its plan, adjust something, and run the optimizer again, often in a new scenario so you can compare before and after. See Demand and Supply for the inputs a scenario carries and Planning Results for what the optimizer returns.

​
Creating a Scenario

Pick a planning model in the toolbar, open the scenario picker next to it, and choose New scenario. Name the scenario and click Create. The scenario opens on its Setup tab, where you enter its inputs; the Results tab shows the plan once the optimizer has run. You can also ask Dexter to build a scenario. A typical request:
“Create a scenario on the weekly model, start date next Monday, using the demand from the June order book and the on-hand inventory from yesterday’s ERP export. Cap the packaging line at 80 hours per week.”
Dexter can also run the optimizer on the scenario and summarize the result. Every input belongs to its scenario and isn’t shared with other scenarios, so one model can drive many scenarios without them interfering with each other.

​
Validating Inputs

ProDex checks a scenario’s inputs automatically whenever they change, without invoking the solver. While the check runs, the button reads Validating…. Run optimizer stays disabled until the inputs pass. When they don’t, ProDex shows the error count (for example 2 validation errors) and the first few messages. Ask Dexter to validate the scenario to see the full list. The checks run in a fixed sequence; later checks are skipped if an earlier structural check fails:
Check 3 also rejects two BOMs for the same entity whose conditions use completely disjoint attribute sets. An order could satisfy both, which is ambiguous. If you split an entity’s recipes by size, every one of its conditioned BOMs must condition on size.
Validation errors are always data setup issues, not solver issues. Fix the inputs and the check runs again on its own. Some problems produce a warning instead of an error and don’t block Run optimizer. The main one is a resource with missing capacity entries, which the optimizer treats as zero capacity. The scenario view doesn’t show warnings; ask Dexter to validate the scenario to see them.
Deleting and re-creating a BOM breaks saved models. A planning model saved before the re-creation still points at the old BOM record, and the scenario fails with a “BOMs not found” error. Re-save the model so its BOM list re-resolves. Re-creating the BOM alone is not enough.

​
Optimizing

Once the inputs pass, click Run optimizer. The solver takes the model plus the scenario’s inputs and finds the production plan that minimizes total loss, subject to resource capacity limits, BOM flow balance, supply timing, and any hard-deadline orders. The solve runs in the background, so you can navigate away. While it runs, the Results tab shows its progress: Optimization queued, then Solving plan, then Finalizing plan. If the scenario already has results, they stay visible but are marked out of date until the new solve finishes. When the plan is ready, a green dot appears on the Results tab. While the solve runs, the button becomes Cancel optimization. A scenario can end in one of these ways: An infeasible or timed-out solve isn’t a system error: the optimizer finished and is telling you something about the inputs. ProDex shows the message as a warning, and the Results tab shows Optimization failed with the reason. Any earlier results on the scenario stay in place.

​
Solver Defaults

Ask Dexter to use a different time limit (up to one hour) or gap (0.5% or wider) for a solve.
The optimality gap is a proof, not an accuracy estimate: a 2% gap certifies that no plan more than 2% better exists. A solve that hits the time limit after finding a plan still returns it, with whatever gap it reached. Ask Dexter for the gap, the solve time, and whether the solver stopped at the gap or at the time limit.

​
When a Scenario Is Infeasible

Infeasibility is not a solver bug. It is the optimizer telling you the inputs cannot all be satisfied at once. When a solve comes back infeasible, ProDex tries to diagnose it automatically. It re-solves with one family of rules relaxed at a time (custom constraints, then resource capacity, then hard deadlines) and reports which relaxation makes a plan possible. Where only a few are involved, it names the specific custom constraints, resources, or hard-deadline orders that block the plan. If the scenario is still infeasible with all three relaxed, it reports that demand can’t be reached from the supply, on-hand inventory, and BOMs alone. The findings appear with the No feasible solution found warning and on the Results tab. The diagnosis runs on a limited time budget, so on a large scenario it can finish without a conclusive finding; the Results tab then shows only “Optimization problem is infeasible.” In that case, relax custom constraints, capacities, and hard deadlines yourself one at a time, or ask Dexter to investigate. The common causes, roughly in order of frequency:
  • A hard-deadline order that cannot be met given resource capacity and the BOM lead-up chain. Relax the tag to soft, add capacity in the constrained intervals, or extend the horizon.
  • A resource with no capacity in the intervals a demanded SKU needs. Remember that missing capacity entries default to zero.
  • Missing raw-material supply for a demanded SKU. Add supply orders for the raws the BOM chain needs, or seed on-hand inventory.
  • Over-constrained custom constraints: for example a minimum-production floor stacked against a maximum-output cap that together exclude every schedule. Loosen whichever constraint is over-restrictive.
Recovery is almost always one of five moves: relax a hard tag, add capacity in the pinch intervals, extend the horizon, add supply, or loosen a custom constraint. Change one thing at a time and re-run so you can see which move unlocked the plan.