Tour planning Restrictions possibilites

[mujeeb]

is there any way to apply these restriction on orders/vehicle ?

we have transport orders with/without fleetId(s) & vehicleClassId(s) (e.g heavy rigid, light rigid,...)
criteria is
order without fleetId can be assigned to any vehicle with/without fleetId
order with specific fleetId only can be assigned to vehicle with same fleetId

same for vehicleClassId i.e.
order without vehicleClassId can be assigned to any vehicle with/without vehicleClassId
order with specific vehicleClassId only can be assigned to vehicle with same vehicleClassId

i have checked
https://xtour-au-n-test.cloud.ptvgroup. ... %7C_____10

but nothing relevant found.

anybody knows is it possible with xTour?

[Bernd Welter]

Hello Mujeeb,

the list of vehicles who are allowed to take a care of a specific order can be defined by various constraints.

• TransportOrder.vehicleID: optional ID of a specific vehicle that should handle the order
• TransportOrder.vehicleCategories: optional list of categories of vehicles who are allowed to take care. Though you can mention several categories at the order each vehicle belongs to not more than one category (e.g. "with trailer" versus "without trailer")
• TransportOrder.vehicleRequirements and TransportOrder.vehicleExclusions: Another option is to demand or forbid specific equipment, e.g. an order requires a shnickshnack and a firlefanz (ficticious categories 1 and 2). In this case only vehicles with at least the categories 1,2 are allowed.

Here is a quick view to the required diagrams:

Diagram Vehicle

Diagram Order

Of course the concept behind this supports many more constraints such as the time windows and operating intervals and the whole quantity based stuff.

Best regards Bernd

[mlauer]

Hi,

I have also a problem related to planning restrictions: A specific vehicle should not be allowed to do a specific order. ("Access permissions" should be the dual problem.)

Example:

transportEquipment:
1 - has special equipment loaded
2 - can do task A
3 - forbidden to access place XYZ

vehicle { id=1, transportEquipment=[1,2,3] }
vehicle { id=2, transportEquipment=[1,2] }
vehicle { id=3, transportEquipment=[1] }

order { id=123, place=XYZ, requirements=[1,2], exclusions=[3] }

In my understanding this should select vehicle with id=2 for order id=123. Right?

Problem: How can I scale this solution to more than 512 "forbidden places"? While orders/places is very dynamic data with lots of records, "transportEquipment" or let's call it "qualification" is a more static and small set of records.

The opposite of "TransportOrder.vehicleID" could be a solution. An array to exclude specific vehicles by order. Is that possible/planned?


Regards,

Markus

[Bernd Welter]

COUNTER QUESTION
Hm, do you always plan so many resources within the same transaction?
There is no proper parameter providing exactly what you need, therefore I'd like to know more about the specific reason WHY the vehicle shouldn't be allowed to be assigned to an order, e.g. because "trailers are not allowed" at the customer? Then I recommend to use categories.

How about getting in touch with your assigned consultant to discuss the individual requirements of your application?
Maybe the output of such a 1:1 discussion can be helpful for the forum afterwards.

Best regards Bernd (who is probably the assigned consultant )

[mlauer]

> Hm, do you always plan so many resources within the same transaction?

To be honest I'm not sure. Let's do some assumptions:

- 10.000 and more possible addresses/locations for orders
- 50 drivers

At each address a driver could have an access limitation/ban. (Also more than one driver could be limited for an address).

If I have 1.000 orders at different addresses and the worst case of 49 banned drivers per address, a tour planning would look like this:

transportEquipment:
1 - forbidden to access place place1
2 - forbidden to access place place2
3 - forbidden to access place place3
...
1000 - forbidden to access place place1000

vehicle { id=1, transportEquipment=[1,2,3,...] }
vehicle { id=2, transportEquipment=[1,2,3,...] }
vehicle { id=3, transportEquipment=[1,2,3,...] }
...
vehicle { id=50, transportEquipment=[2,3,...] }

order { id=123, place=place1, exclusions=[1] }

And that would be already impossible (no more than 512 transportEquipment definitions).
I think, this solutions only scales up to 400 orders with different addresses and some other additional transportEquipment.
Also I'll would have to define the transportEquipment on the fly (Mapping between integer and meaning), what I'd like to avoid.

> e.g. because "trailers are not allowed" at the customer? Then I recommend to use categories.

No. I think it's not about a vehicle category (like "with trailer"), but about specific vehicles/drivers.

> How about getting in touch with your assigned consultant to discuss the individual requirements of your application?

I'll try that. Thank you.

[mlauer]

New idea:

transportEquipments
1 - has special equipment loaded
2 - can do task A
...
400 - vehicle0
401 - vehicle1

vehicle { id=vehicle0, transportEquipment=[1,2,400] }
vehicle { id=vehicle1, transportEquipment=[1,2,401] }

order { id=123, place=XYZ, requirements=[1,2], exclusions=[400] }

The set of transportEquipments/qualifications is split into two parts:
1..399 - static qualifications
400..512 - special vehicle qualifications / each vehicle has a corrosponding qualification

Only drawback: I'll have to keep vehicles and their special qualifications in sync.

[Bernd Welter]

Hello Mr. Lauer,

using the approach with the equipment={.... , VehicleID , ...} sounds valid. As long as the number of drivers plus the "real" skills doesn't exceed the given number of 512 at maximum.

Best regards from Karlsruhe,

Bernd