VRt.Universal [UV] (6.20.2289)


Software interface for universal trip planning.


  • Ability to pick up cargo from any location
  • Possibility of unloading in any location
  • Pair orders of several types: PICKUP (loading), DROP (unloading)
  • Single requests of several types: DROP_FROM_BOX (unloading cargo that is already in the body), PICKUP_TO_BOX (cargo pickup into the body without subsequent unloading), WORK (working at the location without moving the cargo)
  • A complex order can consist of any number of orders of any type
  • Transport and executors are divided into different entities, when planning, the optimal assignment of the executor to the transport occurs
  • The transport has several compartments - each of which can accommodate cargo and has its own characteristics
  • Accounting for the compatibility of cargo with transport in terms of cargo dimensions (length, width, height, additional capacity parameters)
  • Taking into account the compatibility of the cargo-compartment of transport (the ability to take into account the features of the compartment: refrigerator, thermal bag, fasteners, etc.)
  • Substitute applications, i.e. the ability to execute one of the substitute applications, the choice of which is based on its geographic location and time window

Restrictions support

Performer restrictions:

  • Start/finish location
  • Accounting for the performer's way to the transport location
  • Performer's availability schedule is a list of time windows when the performer can move and work on locations
  • The maximum duration of the performer's work during the specified time period

Transport restrictions:

  • Start/finish location
  • Transport availability schedule is a list of time windows when the transport is available
  • The maximum route distance
  • Several compartments in the transport, each with its own parameters
  • Capacity upper limit (weight, volume, number of orders, number of demands)

Order restrictions:

  • Strict time windows
  • Ability to specify different valid time windows for a location and time windows to fulfil the desired demand
  • Accounting for the requests fulfillment order within the route
  • A list of desired time windows with different associated costs


Entities are compatible if the capabilities list of one entity corresponds to the list of restrictions of another entity (example: fleet parameters corresponds to cargo parameters to be delivered).

Supported compatibilities:

Order - Performerorder.performer_restrictionsperformer.performer_features
Order - Not a performerorder.performer_blacklistperformer.performer_features
Cargo - Compartmentorder.cargo.box_restrictionstransport.box.box_features
Location - Transportlocation.transport_restrictionstransport.transport_features
Transport - Performertransport.performer_restrictionsperformer.performer_features
Performer - Transportperformer.transport_restrictionstransport.transport_features
Order - Orderorder.order_restrictionsorder.order_features

Business rule examples:

NameBusiness rule example
Order - PerformerThe driver must have a special license to fulfil the order
Order - Not a performerThe driver is in the blacklist
Cargo - BoxFor transportation of frozen products, a compartment with a special temperature profile is required
Location - TransportRestrictions on the transport height
Transport - PerformerThe truck driver must have the class C driving license
Performer - TransportThe driver is allowed to work on a specific transport
Order - OrderIt is not allowed to transport fish and fruits in the same compartment

Cargo placement

List of possibilities of a object rotations (90 degree step):

  • ALL - can rotate by any axis
  • YAW - can yaw
  • PITCH - can pitch
  • ROLL - can roll


Trip model

The trip is described by the list of states of the executor, while the executor can be in several states at the same time (for example, to be inside the working time window of a location and fulfill an order at the same location).

Possible values ​​of the flags responsible for the geographical location:

  • AROUND_LOCATION - the performer is located near the location - in the process of parking or leaving it.
  • INSIDE_LOCATION - the performer is at the location.

Possible values ​​of the flags responsible for being in time windows:

  • INSIDE_WORKING_WINDOW - the executor is inside the working time window.
  • INSIDE_LOCATION_WINDOW - the executor is inside the location's working time.
  • INSIDE_EVENT_HARD_WINDOW - the executor is inside a hard time window.
  • INSIDE_EVENT_SOFT_WINDOW - the executor is inside the soft time window.

Possible values ​​of flags responsible for actions:

  • ON_DEMAND - the executor is working on the request.
  • WAITING - the performer is in standby mode.
  • RELOCATING - the executor is moving to the next stop.
  • BREAK - the performer is on a break.

An example of a route with multiple states at each point in time

timeset of active flagslocation / order / application / eventcomment
2 / - / - / -starting location
10:10RELOCATING- / - / - / -we go to the first order
10:20AROUND_LOCATION2 / - / - / -arrived at the first order
2 / - / - / -parked
2 / - / - / -waited for the start of the location window and at the same time the availability of the order
2 / 1 / 2 / 3waited for the change of artist
2 / 1 / 2 / 3while working - a soft window happened
2 / - / - / -finished working
2 / - / - / -drove out of the parking lot
- / - / - / -we go to the next order

Planning configuration

For each planning, it is possible to specify a planning configuration that defines the objective function, the desired quality of the routes, and the calculation speed.

The name of the scheduling configuration is passed in the trips_settings.configuration field.

Main configurations:

optimize_distanceArrange as many orders as possible, then optimize the total mileage (the number of vehicles is selected based on the mileage), used by default
optimize_transportsPlace as many orders as possible, while using as little transport as possible, ceteris paribus, optimize the work time of performers
optimize_locality_groupingPlace as many orders as possible, while striving to optimize the visual grouping of routes, but not their number
optimize_cars_then_distanceArrange as many orders as possible, then optimize the number of vehicles, then the mileage
optimize_timePlace as many orders as possible, then optimize the total work time of performers
optimize_cars_then_timeArrange as many orders as possible, then optimize the number of transport, then the total time of the performers
optimize_moneyOptimize the value of "profit - costs", consists of rewards for applications and costs for performers and transports (optimized value is non-negative)

Additional configurations:

visual_groupingArrange as many orders as possible while using as little transport as possible and routes should be visually grouped
optimize_visual_groupingArrange as many orders as possible, then evenly distribute orders taking into account transport accessibility zones (similar to visual_grouping, but visual grouping is calculated differently)
optimize_cars_then_locality_groupingArrange as many orders as possible, then optimize the number of vehicles, then visually group the routes
optimize_cars_then_single_location_grouping_sequencedPlace as many orders as possible, then optimize the number of machines, then reliability

In addition to the existing planning options, it is possible to create an objective function directly for the client's business processes (request configuration).

For development, it is recommended to use optimize_cars_then_distance, since this configuration does not require detailed selection of rates and order values.

Data validation

Input data validation consists of several steps, which are described below.

Validation of planning results (including the search for possible reasons why orders were not planned) is located in the analytics method.

1. Schema check

If the request does not follow the schema, then scheduling is not fully started and such an error is returned along with a 400 code in schema_errors.

We recommend validating the request against the schema (or yaml file) before sending it to the server.

2. Check for logical errors that prevent planning from continuing

Schema-correct data passes the second stage of checking for the possibility of starting planning.

An example of errors at this stage are keys leading to empty entities, or if all orders are incompatible with all performers, i.e. something that makes the planning task pointless.

These errors are returned along with a 400 code in logical_errors.

3. Check for logical errors that prevent planning from continuing

At the third stage, each entity is checked separately.

All entities that have not passed validation are cut out from the original task and are not sent for planning.

Depending on the setting of treat_warnings_as_errors, the results of this type of validation are returned to warnings either with a 400 code or with the scheduling result.

4. Checks in the planning process

Part of the checks can only be carried out in the planning process.

For example - that according to the specified tariffs and according to the current traffic forecast, it is physically impossible to reach a certain point.

The results of these checks are returned in warnings or together with the scheduling result.

Entity relationship diagram