Vehicle properties

Each vehicle or courier must have a unique numeric or string ID set in the id field. The ID must be unique within a single service request. When exporting to Track & Trace, this identifier is used as the courier's username.

You can also specify the vehicle's or the courier's numeric or string ID from your tracking system in the ref field and the courier's mobile phone number in the phone field so that they can be contacted from Track & Trace.

In RouteQ you can define the vehicle capacity in terms of the maximum weight or cargo the vehicle/courier can transport over a single route.

To determine the vehicle or courier carrying capacity, use the capacity field (you can specify just one option):

• capacity.weight_kg: Weight in kilograms or bulk weight.

• The volume, which is measured in cubic meters and set as the product of dimensions:

  • capacity.volume.width_m: Width in meters.

  • capacity.volume.depth_m: Depth in meters.

  • capacity.volume.height_m: Height in meters.

  If you don't know the dimensions, you can set the volume value in one field and enter 1 in the other fields.

• capacity.units: Number of units (pallets, boxes, kegs).

For more information about weight determination, see Weight and volume.

Additionally, you can set the maximum load of a vehicle as a percentage of the specified load capacity. To do this, use the limits request field:

• limits.volume_perc: A percentage of the value specified in capacity.volume.width_m * capacity.volume.depth_m * capacity.volume.height_m.

• limits.weight_perc: A percentage of the value specified in capacity.weight_kg.

• limits.volume_perc: A percentage of the value specified in capacity.volume.

To indicate that overload is allowed relative to a given value, specify a value greater than 100. To leave spare load capacity, for example, to allow for the inaccurate estimation of order dimensions, specify a value less than 100. For example, a value of 110 allows for 10% overload and a value of 90 allows for a maximum load of 90% the specified load capacity.

The vehicle capacity (based on the limits) is a hard restriction that won't be violated. Note that, when calculating the vehicle load, the system takes into account the orders for pickup and delivery. For more information, see Pickup and delivery.

Example

There are two vehicles with a load capacity of 1.5 tons (Vehicle 1) and 3 tons (Vehicle 2) and three orders for delivery with a weight of 1 ton, 1.2 tons, and 1.4 tons, respectively.

When optimizing routes, the 1.2-ton order is placed in Vehicle 1 and the 1-ton and 1.4-ton orders are placed in Vehicle 2.

API request (JSON) ⋅ API response ⋅ View on map

You can specify vehicle properties in the vehicle.specs field. The following parameters can be specified:

• width: Vehicle width in meters.

• height: Vehicle height in meters.

• length: Vehicle length in meters.

• max_weight: Maximum vehicle weight in tons.

• max_weight_kg: Maximum vehicle weight in kilograms (rounded up to the ton when addressing the planning task).

The minimum value is 0 for all the listed properties.

The loading or unloading time at the depot may depend both on orders and vehicle properties (for example, dimensions or equipment).

To specify the amount of additional time required for loading at the depot, use the vehicle.depot_extra_service_duration_s parameter. The time is set in seconds.

Example

2 vehicles with the same load capacity are delivering 13 large orders. The handling time at the depot depot.service_duration_s is 5 minutes (300 seconds). Additional time is set for loading orders into a vehicle at the depot vehicle.depot_extra_service_duration_s: 30 minutes (1800 seconds). As a result of planning, each vehicle will spend 35 minutes at the depot before starting their routes.

API request (JSON) ⋅ API response ⋅ View on map

By default, vehicles and couriers start from the depot. However, sometimes they need to start the route from another point (for example, from their home or parking spot). That's a usual task in the case of sales representatives, service engineers, and other specialists who don't deliver goods, but provide services.

You can implement this requirement using the property vehicle.start_at. In this case, the courier or vehicle will start their route from the specified point with the type garage, rather than from the depot.

A courier can start from one of several depots. These depots have to be listed in the depot_id field (depots that the courier can visit) or starting_depot_id (depots from which the courier can start their route). These lists can overlap. If there are several depots, the algorithm will choose the optimal depot to start from.

If you use the delivery from one of several depots functionality, a courier will be able to pick up orders from any depot they can visit.

You can additionally set the allow_different_depots_in_route and max_middle_depots parameters for a courier. For more information, see Choosing the optimal depot to start from.

For a courier to be able to visit additional depots for reloading orders while following the route, set the allow_different_depots_in_route = true parameter. These depots have to be listed in the depot_id field (depots that the courier can visit) or middle_depot_id (depots for reloading). Depot lists can overlap. If there are orders in several depots, the algorithm will select the optimal depot for reloading.

If the courier can stop at intermediate depots for reloading only at the beginning of the route (before completing the first order), set depots_only_at_run_beginning = true (the default is false).

You can additionally set the max_middle_depots parameter for a courier. For more information, see Visiting an additional depot.

By default, the courier completes the route at the depot where they started. To allow the courier to visit several depots along the route, set allow_different_depots_in_route = true. In this case, the courier can end the route at a depot other than the first one.

Depots where a courier can end their route are specified in the depot_id field (depots that the courier can visit) or ending_depot_id field (depots from which the courier can complete their route). These lists can overlap. If there are several depots, the algorithm will choose the optimal depot to complete the route at.

To have the courier end the route at the same depot where they started, set finish_route_in_starting_depot = true (the default is false). If the courier starts the route not from a depot (visit_depot_at_start = false), they are to return to the depot they stopped at during the second run of the route.

To have the courier end each run at the same depot where that run started, set finish_run_in_starting_depot = true (the default is false). To allow the courier to change from depots between runs, set can_change_depot_between_runs = true (see Start of a new run from a different depot).

If the courier doesn't have to return to the depot after all the orders are completed, use the return_to_depot = false option.

Example 1.1

Two couriers are to deliver two orders: one is a delivery order that needs to be picked up from Depot 1, and the other one is a pickup order to be delivered to Depot 2. The couriers can only make 1 run each, starting at any depot and ending the route at any depot. Both couriers are allowed to stop at different depots during one run, but they cannot stop at intermediate depots.

The solution uses only one courier: they leave Depot 1 after picking up the delivery order, deliver it, pick up the pickup order, and deliver it to Depot 2, where they end the route.

API request (JSON) ⋅ API response ⋅ View on map

Example 1.2

The same as in example 1.1, but the couriers need to end the route at the same depot where they started (finish_route_in_starting_depot = true).

The solution uses both couriers. Courier 1 leaves Depot 1 after picking up the delivery order, delivers it, and returns to Depot 1. The second courier leaves Depot 2, picks up the pickup order, and returns with it to Depot 2.

API request (JSON) ⋅ API response ⋅ View on map

You can plan a route so that the courier starts or finishes on the order that is closest to or furthest from the depot. For example, if you expect to get new orders in the morning, then it would be better to start the route with the orders closest to the depot. That way, it will be easier for the courier to return to the depot to pick them up. On the other hand, by starting the route with the farthest order, the courier would finish closer to the depot in the evening.

If you are not using advanced cost settings, set the following parameters:

• first_edges_penalty_factor: A penalty for the distance from the depot to the first order, the default is 0. If the value is greater than 0, the algorithm minimizes this distance, and if the value is less than 0, it maximizes it.

• last_edges_penalty_factor: A penalty for the distance from the depot to the last order, the default is 0. If the value is greater than 0, the algorithm minimizes this distance, and if the value is less than 0, it maximizes it.

If penalty values are high, routes may be suboptimal in terms of mileage. If penalty values are low, then the first or last order of a route may be selected in violation of any requirements provided it saves on mileage.

If you are using advanced cost settings, use the keywords from the Travel from or to the depot group.

Example

In the example below, there is 1 courier and 10 orders. Two penalties are set: first_edges_penalty_factor = 2 and last_edges_penalty_factor = -2. Planning produces a route that begins with the order closest to the depot and ends with the furthest order.

API request (JSON) ⋅ API response ⋅ View on map

You can define one or more work shifts for a vehicle. Use the vehicle.shifts field to define the shifts.

A shift is a time range when the vehicle is allowed to operate. Shift time includes the loading time at the depot, traveling time, and handover time at order locations.

You can also restrict the maximum shift duration.

To use one or more shifts in Excel, define the following fields:

• shifts.0.time_window: The time window corresponding to the vehicle's operating hours.

• shifts.0.hard_window: The hard time window flag.

• shifts.0.service_duration_s: Time between shifts (in seconds). For example, it can be the time needed to replace the driver or exchange documents.

In the case of a soft time window, you can set additional penalties:

• For time window violation:

  • shifts.0.penalty.out_of_time.fixed: A fixed penalty for one-time violation of the shift's time window.
  • shifts.0.penalty.out_of_time.minute: A penalty per minute of the shift's time window violation.
• For early departure:

  • shifts.0.penalty.early.fixed: A fixed penalty for one-time start of work before the shift's time window.
  • shifts.0.penalty.out_of_time.minute: A penalty per minute of work start before the shift's time window.
• For late arrival:

  • shifts.0.penalty.late.fixed: A fixed penalty for one-time work completion later than the shift's time window.
  • shifts.0.penalty.late.minute: A penalty per minute of work end after the shift's time window.

To limit permissible violations of the shift's time window, you can set a hard window around a soft one.

Example

The request to RouteQ includes one vehicle with three shifts (morning, afternoon, and evening) and three orders, of which one order has a delivery time in the morning, and two others in the evening.

API request (JSON) ⋅ API response ⋅ View on map

By default, a vehicle or courier starts and ends their route at a depot, completing exactly one route during a working day (shift).

If a vehicle can return to the depot anytime during the work shift to pick up additional orders, limit the number of runs using one of the parameters:

• vehicle.shifts.N.max_runs: The maximum number of runs per shift.
• vehicle.max_runs: The maximum number of runs for all a vehicle's shifts.

You can limit either the number of runs per shift or the total number of runs, but not both parameters at the same time.

If no shifts are set for a vehicle, then max_runs is used as a limit on the total number of runs (1 by default).

Example

The example below uses one vehicle with the limited carrying capacity of 2 tons and three orders with a weight of 0.8 tons. The vehicle is allowed to do two runs. This means that after completing two orders, the vehicle can return to the depot to pick up and deliver another order.

API request (JSON) ⋅ API response ⋅ View on map

When planning a route, you can specify the minimum and maximum number of stops in the route. This can be useful, for example, to limit the maximum vehicle workload per day or, on the contrary, make sure that the vehicle gets on the route with a certain minimum number of stops.

For this, RouteQ uses the minimal_stops and maximal_stops shift parameters. You can set the number of stops for each vehicle.

The restriction is not strict and may be violated. If the limit on the minimum number of stops is violated, a penalty applies. The penalty is specified in the following shift fields: penalty.stop_lack.fixed (for making fewer stops than the minimum number) and penalty.stop_lack.per_stop (for each stop missing under the minimum number).

In the same way, if the limit on the maximum number of stops is violated, a penalty applies. The penalty is specified in the following shift fields: penalty.stop_excess.fixed (for making more stops than the maximum number) and penalty.stop_excess.per_stop (for each stop above the maximum number).

Usually when you restrict the number of stops, the solution metrics degrade since the solution favors restrictions at the cost of the optimal route.

Example 1

In the example, the route is built for 3 vehicles that deliver to 15 points. Since there are no restrictions for the route, the route is built the usual way.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

This example has the same conditions as example 1, but sets the limit of 4 minimum stops per vehicle. As a result, the routes changed so that each vehicle visited at least 4 delivery locations.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

This example has the same conditions as example 1, but sets the limit of 5 maximum stops per vehicle. In the result, orders are distributed evenly among all vehicles, even though several orders are located next to each other and can be completed by one vehicle.

API request (JSON) ⋅ API response ⋅ View on map

Sometimes you may need to extend the courier's working hours. But you also need to limit the maximum shift length and set the window you want to fit into. Let's day you have a 14-hour time window for courier delivery (for example, from 8:00 to 22:00), but each courier shouldn't work more than 8 hours.

RouteQ helps you schedule shifts with hard time windows and preferred lengths. In this case, the courier's shift length doesn't affect the work start time. It only affects the time that they spend completing orders.

The maximum shift length can be set as a soft restriction shifts.N.max_duration_s that can be violated for a penalty or as a hard restriction shifts.N.hard_max_duration_s that can't be violated:

• When planning with a soft restriction, the workload that doesn't fit into one courier's preferred shift is distributed among others or to the same courier, but with penalties for violating the shift length. All orders that can't be completed in max_duration_s are added to the route with the penalty specified in the shift.penalty.late field (if applicable) or in the shift.penalty.out_of_time field all other times. The total route penalty for violating the maximum shift length is shown in the API response in the overtime_penalty field. If the estimated order cost including penalties is higher than the cost of completing the order by another courier, the order is handed over to another courier.

• When planning with a hard restriction, the courier's shift never exceeds the hard_max_duration_s value.

If you use both restrictions, the hard one can't be less than the soft one. By default, max_duration_s is 2 days, and hard_max_duration_s is 30 days.

Example 1

Let's say the shift window shifts.N.time_window is from 8:00 to 23:00. By default, routes will be built to use the minimum number of couriers.

If you specify max_duration_s = 14400, the load is distributed between couriers, and each of them works for approximately 4 hours (the shift length is set in seconds). Some couriers may still work more than 4 hours, because it's less costly to pay for extra hours than to hand over the order to another courier.

As a result of planning, orders are distributed among three couriers. One courier's shift went over 4 hours. The penalty amount is shown in the API response in the overtime_penalty field.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

The same as in Example 1, but with hard restrictions on the maximum shift length: hard_max_duration_s = 14400. When planning, all couriers are given shifts that are 4 hours or less. As a result, the number of couriers increased to 4.

API request (JSON) ⋅ API response ⋅ View on map

In some cases, you need to limit the mileage per vehicle. For example:

• The planning includes hired cars, and their rate implies limited mileage.

• You can assign specific vehicles for far-away points. Then you can limit the mileage for other vehicles.

The shifts.max_mileage_km parameter determines the maximum vehicle mileage per shift. The entire mileage is taken into account, including:

• Traveling from the depot or starting point to the first point from the order list.

• Returning to the depot or end point of the route from the last point in the order list.

The restriction is soft: the algorithm may violate it. Penalties are set in the fields:

• shifts.penalty.max_mileage.fixed: A fixed penalty for exceeding the maximum mileage (1000 by default).

• shifts.penalty.max_mileage.km: A penalty per each kilometer in excess of the maximum mileage (100 by default).

If the maximum mileage per run is critical to you, and the vehicle can do several runs per shift, create multiple identical shifts (see Example 2).

If the courier uses public transit, only the walking part of the route is returned as the mileage.

Example 1

The mileage limit per courier is 50 km. A big penalty is applied in case of violation. In the result, the planned mileage on any route doesn't exceed 50 km.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

There is one courier and each their run must be limited by 50 km. For this, the courier must have several shifts with the same time windows and mileage restrictions. The result includes 3 routes, each one less than 50 km long.

API request (JSON) ⋅ API response ⋅ View on map

To set the preferred area of work for a vehicle so that the route includes orders near a certain location, use the global_proximity_attraction_point parameter. In the parameter value, specify the location id with the garage type. This is used as a “hotspot”: the algorithm aims to reduce the total distance between orders on the route and this location.

The proximity of routes to the hotspot is determined by the options.global_proximity_factor option: the greater its value, the denser the grouping. For more information about this option, see Grouped routes.

The maximum distance from the route locations to the “hotspot” is stored in the max_distance_to_attraction_point_m parameter, which can be used to calculate the cost of the route. The total sum of distances from all orders to the “hotspot” on the route affects the penalty for insufficient route grouping.

Other ways to group orders geographically

• You can use the global_proximity_factor option to build grouped routes without setting a “hotspot”. This option only works for vehicles that don't have the global_proximity_attraction_point parameter set.
• By using geofences for vehicles, you can set restrictions on delivery zones. The geofence restriction can't be violated. In contrast, the route grouping settings are a more flexible tool.

Example 1

Three vehicles have to deliver 15 orders. The route is calculated based on the order weight and vehicle capacity. There are no other restrictions on the route.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

The same as in example 1, but each courier has a set “hotspot” that shows their preferred area of work. As a result, the routes are more grouped. The maximum distance from the order to the “hotspot” on the route is 20,663 m.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

The same as in example 2, but one of the couriers has a different “hotspot”. Because orders are regrouped, the location of routes on the map has changed. The maximum distance from the order to the “hotspot” increased to 28,528 m.

API request (JSON) ⋅ API response ⋅ View on map

You can specify different cost-of-use components for each vehicle in the query to RouteQ. To set the cost-of-use for the vehicle or courier, use the optional vehicle.cost field.

RouteQ lets you define the following main cost components:

• cost.fixed: The fixed cost-of-use for the vehicle.

• cost.hour: The cost per hour of work.

• cost.km: The cost per kilometer of mileage.

• cost.location: The cost per visit of one order.

• cost.run: The cost per run.

• cost.tonne_km: The cost per ton-kilometer of transport work.

In this case, the cost at which the algorithm selects the optimal routing option is used. That's not the actual rate for using the vehicle, but rather the algorithm's settings.

You can also set the cost-of-use for the vehicle or courier as an arithmetic expression. For more information, see Advanced cost settings.

You can set the cost-of-use for the vehicle or courier as an arithmetic expression. When planning, you can calculate the cost with one expression in the vehicles.cost field or use multiple expressions in nested fields:

• cost.route: For a route.
• cost.shift: For a shift.
• cost.run: For a run.

The expression can use keywords and mathematical notation given in the tables below. To check the expression, use an HTTP request.

Keywords for route parameters

Route metrics are calculated using the following formulas:

• total route duration transit_duration_h = walking_transit_duration_h + driving_transit_duration_h
• total route length distance_km = walking_distance_km + driving_distance_km

The calculation of variables that are used in routes with walking parts is influenced by the transportation method:

• walking: The entire route is traveled on foot, and the distance driving_distance_km and duration driving_transit_duration_h equal 0.
• transit:

  • driving_distance_km = 0: It's assumed that the courier visited all orders on foot (there isn't enough data to calculate the distance traveled by public transport).
  • driving_transit_duration_h is calculated based on other data received when solving the problem (it may be non-zero).

Mathematical notation and functions

Examples of expressions

• 500 + 500 * has_location(in_zone('West')): If the route has a stop in the West zone, then the expression will return 1000, otherwise, 500.
• 450 * location_count(in_zone('West') | in_zone('North')): Counts the number of stops in at least one of the two zones (West, North) and returns that number multiplied by 450.
• 1000 + has_location(in_zone('West') & has_load_type('Freeze')) * 500: If there's at least one stop in the route that's in the West zone and has the Freeze load type at the same time, the expression returns 1500, otherwise, 1000.
• 100 * (has_location(in_zone('West')) & has_location(in_zone('North'))): If there's at least one stop in the West zone and at least one stop in the North zone (there can be one stop in both zones or two different ones), the expression returns 100.
• 100 * has_location(in_zone('West') & in_zone('North')): If there's a stop that's in the West and North zones at the same time, the expression returns 100.
• 100 * location_count(is_pickup() & in_zone('West') & !has_tag('Return')): The expression counts the number of pickup orders that are in the West zone and at the same time don't have the Return tag, and returns their number multiplied by 100.

Calculating the payment the courier receives for completing the route. During planning, you can calculate payouts using one expression in the vehicle.payout field or use multiple expressions in nested fields:

• payout.route: For a route.
• payout.shift: For a shift.
• payout.run: For a run.

In the expressions, you can use the same keywords and mathematical notation you use to calculate the cost of the route for the company (the vehicle.cost field).

If the courier has the vehicle.payout field set, you'll see the following fields in the solution metrics:

• run_payout: Payout for the run calculated using the payout.run formula.
• shift_payout: Payout for the shift calculated using the payout.shift formula. Shown only for the first run of the shift.
• shift_total_payout: Total payout for the shift. It includes the payout for the shift calculated using the formula plus the payout for all the shift's runs. Shown only for the first run of the shift.
• route_payout: Payout for the route calculated using the payout.route formula. Shown only for the first run of the route.
• total_payout: Full payout for the route, including the payout for the route calculated using the formula plus the payout for all the shifts. Shown only for the first run of the route, the other runs have it as 0.

If the payout field is set for at least one courier, the planning results also have the total_payout metric, which is the total amount to be paid to couriers.

Example 1

Two couriers are delivering 40 orders, each courier makes 2 runs. The couriers' cost for the company is set by the expression in the cost field. For courier 1, the payout for the completed route is calculated using the expression in the payout field: this amount is displayed in the metrics of the first run and is equal to 5000 units. For Courier 2, the payout is not calculated, so the total_payout amount is also equal to 5000 units.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

Two couriers are delivering 40 orders. For Courier 1, the payout calculation is set as follows: starting the shift — 3000 units, each kilometer of the route — 10 units, each delivered order — 50 units. If they deliver more than 10 orders during the shift, they receive a bonus of 500 units. For Courier 2, the payout is not calculated.

As a result of planning, Courier 1 makes two runs and delivers 20 orders. For each run, run_payout is applied (1232 and 1053 units), as well as shift_total_payout for the shift (2785 units, including the shift_payout bonus of 500 units) and route_payout for the route (3000 units). In total, the courier gets total_payout of 5785 units.

Excel file ⋅ API request (JSON) ⋅ API response ⋅ View on map

When you set up a vehicle or courier in a request to RouteQ, you can define the rules (or tags) for its compatibility with orders.

Compatibility rules may be required if a vehicle has special equipment that's necessary to fulfil a particular order, like an isothermal van for transporting food.

Vehicle and order compatibility rules (vehicle tags) are set in the following fields:

• vehicle.tags: The vehicle properties that can partially match the properties required to fulfill the order.

• vehicle.excluded_tags: The vehicle properties that must not match the properties required to fulfill the order.

To set the order tags, use the location.required_tags field in the request.

Vehicle tags can be set as strings or regular expressions. Tags can be separated by commas in strings. In this case, the vehicle can deliver the order if at least one of the listed vehicle tags matches the order tag or if the order has no tags. Regular expressions are used to describe the more complex logic and vehicle/order compatibility rules.

RouteQ uses POSIX Extended regular expression syntax. You can test your regular expressions at Regex101.

Let's look at some real-life cases of using tags.

Example 1

Let's take a use case when a transportation company delivers food and drinks in small bulk quantities. Some foodstuff must be delivered in isothermal trucks only. At the same time, all drinks and some foodstuff can be delivered without refrigerators. In addition, some customers can only accept a cargo if a vehicle is equipped with a tail lift.

To set these order restrictions, specify the following tags in the location.required_tags field:

• TAIL_LIFT: For orders that can only be unloaded if a vehicle is equipped with a tail lift.

• ISOTHERMAL_TRUCK: For orders containing goods that require temperature-controlled transportation.

• NORMAL_TRUCK: For orders that do not require special conditions of transportation.

To set vehicle features, use the following tags in the vehicle.tags field:

• TAIL_LIFT: For vehicles equipped with a tail lift.

• ISOTHERMAL_TRUCK: For isothermal vehicles.

• NORMAL_TRUCK: For regular vehicles without an isothermal van.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

Let's take a use case when some orders have a restriction on the vehicle body height due to different height of unloading zones.

For example, there are orders with the restriction on body height of 2 meters, 2.3 meters, and 2.5 meters. Then they should have the appropriate tags: Max_200, Max_230, and Max_250.

For the vehicles, tags are set in a more complex way, since a vehicle up to 2 meters high can deliver any orders, whereas a vehicle up to 2.8 meters high can only deliver some orders. That is, if you only use tags, then at a vehicle's height:

• Up to 2 meters, the vehicle.tags field will contain all Max_200, Max_230, and Max_250 values.

• From 2 to 2.3 meters, the vehicle.tags field will contain the Max_230 and Max_250 values.

• From 2 to 2.3 meters, the vehicle.tags field will contain the Max_250 value.

• More than 2.5 meters, the vehicle.required_tags field will be empty.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

Let's take a use case when some orders have a restriction on the arrival of vehicles with a certain load capacity (the OR condition applies when any of the corresponding vehicles is suitable).

For example, there are vehicles with different load capacity: 1, 3, 9, and 15 tons. Let's fix these characteristics using vehicle.tags tags. Since you'll have to combine these tags when describing orders, let's set them using regular expressions: .*1TON.*, .*3TON.*, .*9TON.* and .*15TON.* (.* means “any substring”).

The vehicle load capacity limit for some orders is from 1 to 15 tons, from 3 to 9 tons, and from 1 to 3 tons. This limit is set for the order by a string with a regular expression that includes tags of all suitable vehicles. That is, the location.required_tags field will contain the following regular expressions at the required load capacity:

• From 1 to 15 tons: ##1TON##3TON##9TON##15TON##.
• From 3 to 9 tons: ##3TON##9TON##.
• From 1 to 3 tons: ##1TON##3TON##.

API request (JSON) ⋅ API response ⋅ View on map

Orders may have incompatible types, which you can set using the following parameters:

• options.incompatible_load_types: Sets order incompatibility for all vehicles in the same way. To learn more, see the Order incompatibility section.

• vehicle.incompatible_load_types: Sets order incompatibility for a specific vehicle by enabling you to take vehicle features into account.

• vehicle.onboard_incompatible_load_types: When this is set to false (by default), order incompatibility remains in effect throughout the entire run, and when the value is true, then only while the orders are in the vehicle.

For example, different temperature modes are required to transport milk and ice cream. If the vehicle has one compartment, it can transport either milk or ice cream. If the vehicle has two compartments with different temperature modes, it can transport milk and ice cream at the same time in different compartments. In this case, specify the order incompatibility vehicle.incompatible_load_types for vehicles with one compartment. Don't use this parameter for vehicles with two compartments and don't specify incompatible types options.incompatible_load_types for orders in general.

If orders are incompatible for reasons other than vehicle characteristics, set vehicle.onboard_incompatible_load_types = true. For example, if orders from competing companies shouldn't be transported at the same time, the courier will pick up and deliver each company's orders separately without stopping at a depot. This reduces mileage and time en route.

Example 1

The delivery consists of 4 addresses with the following order types:

• Order 1 (id = 1): flowers.

• Order 2 (id = 2): flowers.

• Order 3 (id = 3): flowers, sweets.

• Order 4 (id = 4): flowers, ice-cream.

Flowers and sweets are incompatible for delivery in the same vehicle. Moreover, simultaneous delivery of flowers and ice-cream in vehicle 2 is prohibited, but simultaneous delivery of flowers and sweets is permitted. Then the solution will contain delivery of orders 2 and 4 in the first vehicle and delivery of orders 1 and 3 in the second vehicle.

API request (JSON) ⋅ API response ⋅ View on map

Example 2.1

You need to have 3 orders from different companies picked up and delivered. Orders 1 and 2 and orders 2 and 3 cannot be delivered together, because they belong to competing companies.

As a result of planning, the courier picks up and delivers orders 1 and 3, then returns to the depot to load and deliver order 2 as part of a new run.

API request (JSON) ⋅ API response ⋅ View on map

Example 2.2

The same as in example 2.1, but vehicle.onboard_incompatible_load_types = true.

As a result of planning, the courier picks up and delivers order 2, and then picks up and delivers orders 1 and 3 without visiting the depot. This means less mileage and time en route.

API request (JSON) ⋅ API response ⋅ View on map

You can set limits for vehicles by delivery zones. You can set zones that the vehicle can deliver orders to using the vehicles.allowed_zones parameter:

• The vehicle can deliver orders in any zone specified in the allowed_zones parameter.

• If you don't specify the availability zones, the vehicle can deliver orders without any limits.

• The order can't be delivered if availability zones are specified for all vehicles, and the order location doesn't fall into any of them.

Set the zones forbidden for delivery using the vehicle.forbidden_zones parameter. The vehicle can't deliver orders to any of the zones specified in the forbidden_zones parameter.

When orders are being assigned, geofence incompatibility is taken into account: both the global option and the values set for individual couriers. When planning routes, you can also cancel all limits related to geofences.

Example

This example shows 4 orders and 2 vehicles, 4 geofences are set in the interface. Coordinates automatically determine how orders pertain to geofences:

• Order 1 — simultaneously in zone1 and zone2.

• Order 2 — in zone1.

• Order 3 — simultaneously in zone2 and zone3.

• Order 4 — in zone4.

The availability of geofences for vehicles determined:

As a result, Vehicle 1 delivers Orders 1 and 2, Vehicle 2 delivers Order 4. And Order 3 remains unallocated, because its address is located in the zones forbidden for both vehicles.

API request (JSON) ⋅ API response ⋅ View on map

When building routes, it is assumed by default that a courier uses a passenger car for delivery (load capacity less than 2.5 tons). To specify delivery on foot, by truck, or by public transit, use the vehicle.routing_mode parameter. If all couriers have the same delivery method, you can use the routing option options.routing_mode.

Example 1

The example below uses the transit transportation method for all couriers. As a result, couriers deliver orders using public transit with optimal order allocation.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

The example below uses the transit transportation method for one courier and the driving method for another courier. Orders are distributed among couriers so that the vehicle delivers to locations situated further away from public transit stops or from each other.

API request (JSON) ⋅ API response ⋅ View on map

By default, the service plans a route only with stops that are necessary for cargo delivery. However, couriers often can't work without stopping: they need to have lunch breaks, and you must take these into account when you build routes. Moreover, on long-distance runs, drivers are required to make stops at certain intervals to meet the work and rest requirements.

To control the couriers' working mode, use the vehicle.rest_schedule.breaks object. You can describe simple or complex patterns of rest and maintenance breaks and other activities.

The user can specify which vehicle should deliver particular orders. This is useful:

• For additional planning when you have pre-planned routes.

• When the order requires a specific vehicle.

To specify pre-planned orders for the vehicle, use the vehicle.planned_route option. This option has the following properties:

• When planning, all orders that you specify in vehicle.planned_route can't be unallocated, even if strict restrictions are violated, such as vehicle capacity or time windows for which hard_window = true.

• By default, the order sequence set in planned_route isn't fixed. When re-planning, orders can be arranged in a new sequence.

• If you need to save the route that's specified in planned_route without saving changes (sequence changes and adding new orders), use vehicle.fixed_planned_route = true.

For each order in planned_route, be sure to specify the vehicle shift (even if the vehicle only has 1 shift).

If in planned_route several shifts are specified, you can lock orders for shifts using the fix_planned_shifts = true option. By default, the value is false.

If a courier arrives too early, delivery time of the order is determined by the vehicle.wait_if_early parameter:

• true: The courier waits for the order time window to start (default value).
• false: The courier handles the order as soon as they arrive.

In the planned_route field, you can specify depots for reloading, which a courier needs to visit when traveling along the route.

Example 1

Both couriers had pre-planned orders in planned_route. As a result, these orders were given to these two couriers.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

This example involves 1 vehicle that has orders linked to it via planned_route. The total weight of the orders exceeds the vehicle capacity, but the route is still being planned (because orders specified in this option can't be unallocated). But the ask status is UNFEASIBLE.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

Theoretically, 2 couriers could deliver all 20 orders without overload and without being late. But a fixed sequence is specified for courier 1 using the vehicle.fixed_planned_route = true parameter, so they'll only deliver orders from this sequence. Courier 2 isn't limited by a strict plan, so they'll take as many orders as they can carry. Several orders will remain in the depot, despite the fact that courier 1 has the space and time.

API request (JSON) ⋅ API response ⋅ View on map

Example 4.1

2 couriers need to deliver 15 orders in 2 shifts. Using the planned_route option, orders 1-8 are assigned to courier 1, and orders 9-15 to courier 2. At the same time, it's indicated that orders 1-4 and 9-12 must be delivered during the first shift, and orders 5-8 and 13-15 during the second shift. Since fix_planned_shifts = false and couriers manage to deliver all orders within one shift, the distribution of orders by shifts is not taken into account.

API request (JSON) ⋅ API response ⋅ View on map

Example 4.2

The conditions are the same as in example 4.1, but the option fix_planned_shifts = true. This means the shifts during which orders have to be delivered are taken into account.

API request (JSON) ⋅ API response ⋅ View on map

The visited_locations feature is useful if:

• The beginning of route must follow a particular path.

• You need to change the start point when doing additional planning.

The route must be fixed for each courier individually.

To do this, specify the visited_locations array in vehicles and describe the points of the fixed route using the following parameters.

* Required parameter

Example 1

There are 5 orders in this example. The sequence of orders 1, 2, 3 is fixed in visited_locations. Orders 4 and 5 can be delivered in any sequence.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

In visited_locations, it's specified that the route must start with order 2 at 10:00.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

The order sequence 1, 2, 3 is set as in example 1. It's also specified that departure from order 1 must be at 08:20 and from order 3 at 11:00.

API request (JSON) ⋅ API response ⋅ View on map

Example 4

There are 8 orders in this example. The specified sequence is orders 1, 2, 3, then the depot, then order 4. The courier may deliver the remaining orders in any sequence.

API request (JSON) ⋅ API response ⋅ View on map

To calculate the speed of the vehicle when building a route, RouteQ uses Yandex Maps data about traffic and the speed specified in the request. Although the trucks usually move slower in traffic jams, some drivers drive more aggressively and arrive earlier than the calculated timeframes.

To compensate for such deviations, RouteQ has the travel_time_multiplier option where you can specify a fractional value. If the value is 1, the calculation is made for the vehicle with the expected average speed. At smaller values (for example, 0.8), the calculation accounts for faster vehicles. At higher values (for example, 1.2), the calculation accounts for slower vehicles.

Example 1

In the example below, the routing request is sent without adjusting the transit time. As a result, the vehicle delivers the order in 4 hours and 20 minutes, with 3 hours and 40 minutes spent moving between the points.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

The same as in example 1, but with the travel_time_multiplier parameter set to 0.5. In the resulting route, the courier delivers the order in 2 hours and 25 minutes, spending 1 hour and 45 minutes moving between the points. However, time spent on parking and handover remains unchanged.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

The same as in example 1, but with the travel_time_multiplier parameter set to 2. In the resulting route, the courier delivers the order in 7 hours and 58 minutes, spending 7 hours and 18 minutes moving between the points. Traveling the route takes more than twice as long as in example 1, because part of the route occurs at peak hours, and the vehicle can't drive at the maximum speed. Time spent on parking and handover remains unchanged.

API request (JSON) ⋅ API response ⋅ View on map

To the courier needs some time to hand over the order on arrival. This time includes parking, riding the elevator, handing over the delivery, and paperwork. RouteQ ensures that by using the order's service_duration and shared_service_duration fields. However, some couriers deliver goods faster than others. For example:

• In the case of parallel planning for vehicles and couriers using public transport, couriers who travel by public transport don't have to spend time parking. As a result, they need lower handling time.

• Some couriers are faster than others. Experienced couriers usually spend less time handing over orders.

To compensate for the difference in courier time, RouteQ has the service_duration_multiplier and shared_service_duration_multiplier options that affect the handling time for a specific courier. If the value is 1, the handling time is the same as in service_duration or shared_service_duration. If the value is less than 1, the handling time is lower. If the value is greater than 1, the handling time is higher.

Example 1

In the example below, the routing request is sent without adjusting the handling time.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

In the example below, the same request is sent to RouteQ as in example 1, but with the service_duration_multiplier parameter set to 0.5. The calculated service order is half the time specified in example 1.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

In the example below, the same request is sent to RouteQ as in example 1, but with the service_duration_multiplier parameter set to 2. Handling time is twice as long as in example 1.

API request (JSON) ⋅ API response ⋅ View on map

To build an optimal route, the algorithm minimizes the wait time between route points. But there are cases when it's useful to shift delivery to an earlier time. For example:

• You have to minimize the risk of late arrival.
• It's more comfortable for the courier to travel in the daytime.

To deliver goods as early as possible, use the penalty.arrival_after_start penalty, which consists of two parameters:

• average_h: Sets the penalty amount for the average arrival time after the start of the time window. When using the option, we always recommend specifying this value.
• as_soon_as_possible: Determines whether to start the route as early as possible. The parameter takes the value true or false (by default). It is specified in addition to average_h.

If you don't use the penalty.arrival_after_start penalty, the route will be built with the minimal wait time between points and the latest possible start time from the depot.

When using the penalty, the algorithm will build routes to start them earlier, provided it doesn't reduce quality.

If the route must start as early as possible (even if it causes additional waiting), specify penalty.arrival_after_start.as_soon_as_possible = true.

Example 1

The route includes 4 orders with different time windows. The earliest start of the time window for order 5 is 08:00. The courier starts from the depot at 11:02 and arrives at the first delivery point at 11:40. Order 5 is delivered at 12:59.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

The same data is used as in example 1, but the penalty is set for the average arrival time after the start of the time window using the penalty.arrival_after_start.average_h parameter. The courier starts from the depot at 06:59, waits for 8 minutes, and then delivers the earliest order (order 5) at 08:00.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

The same data is used as in example 2, but the penalty.arrival_after_start.as_soon_as_possible = true parameter is additionally set. The courier starts from the depot at 06:00, waits for 1 hour and 7 minutes, and delivers the earliest order (order 5) at 08:00.

API request (JSON) ⋅ API response ⋅ View on map

A trailer is a truck (tractor) with a trailer attached. You can place orders in the tractor and in the trailer, while one order can be loaded partially into the tractor and into the trailer.

To describe the trailer, use the trailer object.

Sample trailer description in a request:

{
    "trailer": {
        "capacity": {
            "weight_kg": 10000,
            "units": 200
        },
        "max_capacity_difference": {
            "units": 10,
            "weight_kg": 0
        },
        "cost": {
            "fixed": 1000,
            "km": 10
        },
        "decoupling_time_s": 300,
        "coupling_time_s": 300,
        "rolling_time": {
            "fixed_time_s": 3000
        }
    }
}
Copied to clipboard

For more information about using a tractor with a trailer, see Using a trailer.

To prevent a heavy truck from carrying a single small order across town, use the min_stop_weight parameter. Using this parameter, you can specify the minimum total weight that a vehicle will deliver to a single location. This is relevant when planning freight transportation by vehicles of different capacity.

The restriction is soft: the algorithm may violate it. Penalties are set in the fields:

• penalty.min_stop_weight.fixed: A penalty for violating the minimum total weight for all orders in a single location (1000 by default).

• penalty.min_stop_weight.kg: A penalty for each kilogram that the total order weight delivered to a single location (50 by default) is short.

For more information about using vehicles with different capacity, see Transport with different load capacities.

Example 1

Two vehicles with capacities of 1500 and 10,000 kg are delivering orders weighing 100, 500, 900, and 9000 kg. The large truck gets both light and heavy orders.

API request (JSON) ⋅ API response ⋅ View on map

Example 2

For a vehicle with a capacity of 10,000 kg, the specified value of min_stop_weight is 1000. As a result, the larger vehicle only gets the order weighing 9000 kg.

API request (JSON) ⋅ API response ⋅ View on map

Contact support