Page 1 of 1

Flexible endtime for tour

PostPosted: Tue Oct 09, 2018 5:12 pm
by MichaelSchwabl
In our scenario we have timewindows for all our transportorders defined.
We have also regular operatingintervals for our vehicles defined.
Then there are several transport ordes which are already bound to a fixed vehicle. We do this by setting the vehicleId.
Is it possible that vehicles with fixed transportorders, get those orders assigned anyway, even if this would violate the end time of the operating interval.

We are searching for a solution, where we have a dynamic enddate for some tours. But of course we need some costs in the optimization, so that those tours do not get any new ordes attached to the end.

Re: Flexible endtime for tour

PostPosted: Wed Oct 10, 2018 6:53 am
by Bernd Welter
Hello Michael,

here are my thoughts - not 100% what you want to hear but at least a start:
  • A move such as "insert unscheduled order into tour" or "change sequence of orders" will not be proceeded by the algorithm if the result tour is violated afterwards. So you initial requirement is answered with "nope!".
  • If you want to be sure that the fixed orders are scheduled on a specific vehicle even though they violate the constraints you might put them into the input plan. But: if a single tour of an input plan is violated the algorithm will not assign further orders to that chain at all. (Check this article)
  • If you want a specific order to be the last one on a tour you might take a look at the TransortPoint's property [url=http://xserver.ptvgroup.com/fileadmin/files/PTV-COMPONENTS/DeveloperZone/Documents/xServer_public/manual/Default.htm#API-Documentation/xtour/API_Documentation.html#com.ptvag.xserver.xtour.TransportPoint%3FTocPath%3DDeveloper's%2520Guide%7CAPI%2520Documentation%7CAPI%2520Documentation%2520PTV%2520xTour%7CComponent%2520xtour%7CClasses%7C_____73]tourSection[/url]. This property can be assigned the value 1000 which means "do not schedule another order's transport point after me".
Let me know your feedback,
maybe we can get closer to your usecase,

Bernd