How to analyse unscheduled orders?

[Bernd Welter]

Hi there,

Important update 4.2.2026: as we invented a dedicated new output property named "UnscheduledOrders" in Version 1.45 (4.2.2026) some parts of this thread may required your attention!

sometimes dispatchers want to know why a certain order hasn't been scheduled. Let me explain how to approach this in Optiflow API.
Let me first define three categories of orders at the end of a given planning - just my personal approach:

• Category GREEN: an order has successfully been assigned to a vehicle
• Category RED: an order is not assigned and there's an individual reason why such an order remains unscheduled, e.g. because
  • none of the vehicles has sufficient quantities
  • no driver is available at the time the order's tasks have to be served
  • no vehicle has the required equipment
  and to make it more complex: no vehicle is available that serves all the required constraints at the same time
• Category YELLOW: a yellow order is not part of the output plan but the algorithm
  • either did not manage to schedule the order in the plan's the algorithm has evaluated (at least not yet!)
  • or the algorithm decided to sacrifice the order for the sake of another order (always cost driven)

  

  Chart shows the evolution of the categories in a 2 minute planning (gathered the status every 6-10 seconds): RED contribution is stable. RED/GREEN changes with the time: more and more yellow is getting transformed into green. (sideinfo: the difference between solid and transparent is: solid means a change in the KPI)

  Unscheduled3.png (4.11 KiB) Viewed 3907 times

So what can you derive from this?

• Giving the algorithm more duration in the settings will definetly not convert a red order into a green/yellow one.
• But there's a chance that increasing the duration / waiting longer will manage to transform a yellow into a green.

How to detect category...

• RED: if an order appears in the warnings with ROUTE_OPTIMIZATION_NO_VEHICLE_FOR_ORDER this means he is RED.

  

  BUT: at least today this is not an equivalence: it might happen that from a logical perspective should be seen as RED but the warnings do not report the order as RED.
• GREEN: well, it appears in the output tours ...
• YELLOW: appears in the input but is neither GREEN nor RED

  

  But you can also determine the "number of yellow" by checking the metric's "numberOfUnscheduledOrder" (=yellow+red) and subtract the red one's (based on the proper warnings)

[Bernd Welter]

Just a sidenote / an impulse:
consider to create a client based set of methods that enable your application to identify unplannable orders - this can already take place outside a request, though the profound tests will also be performed inside the optimization routine:
Is there at least one vehicle that

• has all the required equipment for the order (based on categories and constraints)
• AND has sufficient quantities for the order (based on load / maximumLoad)
• AND that is available at the time that the order needs to be served? (based on timeslots)

If not all these lightweight conditions apply such an order can be removed from the input. And once these orders have been purged you could also remove locations (not depots!) that are no longer referenced by at least one order.

Here's how I implemented this.

• Via client logic I determine the number of orders and vehicles that refer to a constraint (columns "Orders", "Orders_Rel" and "Vehicles", "Vehicles_Rel")
• If a OrderVehicleConstraint provides "violationCost" it is a soft constraint, otherwise hard
• For soft constraints I define what I call "potential": the additional coists that apply if the constraint is violated each time.
• Then I compare the vehicles, orders depending on the type
  • line 0 / 1 : constraint useless - categories do not appear at vehicles / orders
  • line 2 : there's an order and no vehicle can serve it - will remain unscheduled
  • line 3 : there's an order that is forbidden for all vehicles in the fleet
  • line 4 : constraint doesn't apply to at least one order
  • line 5 : two orders define a certain prohibition. As this is a soft constraint the potential is 1000.
  • and so forth

[Bernd Welter]

Hi there,

ATTENTION: we made as significant new approach of analyzing unscheduled orders with Version 1.45.

As a consequence we will reduce the amount of info in the warnings in the future - so some parts of the thread may become obsolete.