Skip to main content

Scenarios

Planning​

A typical planning scenario consists of 3 stages, which are discussed below.

Data preparation​

  • Preparation of orders - all orders are converted for the required number of hours in advance (from an hour to 4 months), which are ready for planning.

  • Preparing resources - all resources (performers, vehicles) that are available X hours ahead are converted.

Start scheduler​

  • Calling the planning method - prepared json (which contains Orders and Resources) and an authorization token (api_key) are passed to the planning method

  • Error handling - if the response code is different from 200, then you need to process the error - its number and details will come in response to the request.

  • Receiving a response - if the response code is 200, then the received data must be saved for further processing.

Handling the result​

  • Trips - the structure contains assignments of orders to performers.

  • Statistics - the structure contains general statistical information about all trips.

  • Validations - the structure contains information about the validity of the input data.

Operating modes​

Planning requests can be executed in synchronous and asynchronous mode.

Synchronous​

In the synchronous version, the result comes in response to the input data.

warning

This option is recommended only for development and testing on small tasks (up to 100 entities, up to 1 minutes of planning).

Asynchronous​

In the asynchronous version, in response to the data, a decision identifier is received, by which you can get the current progress of execution and, if the planning is completed, the result of the planning.

This option is recommended for use in the main system.

Planning quality​

The quality of planning depends on the following main parameters:

  1. Quality of initial data
  2. Correct conversion of initial data into a business task
  3. Scheduling settings including scheduling times
  4. Scheduling Configuration
  5. Dedicated server capacity

Update and reschedule​

The trip consists of two important parts:

  • actions (planned actions with orders)
  • waitlist (assigned but not scheduled orders)

To update trips, recalculate the tail and reschedule orders, it is possible to transfer existing trips in the input data to the planning service.

In this case, the orders passed to actions and waitlist will be scheduled only for the executor to whom the corresponding trip is assigned.

Passed in actions, waitlist and new free orders are planned together and do not have a special priority, so when passing a trips in the input data, you need to take into account important points:

  • free orders may be included in the new trips
  • orders from the transferred trip cannot get to other performers
  • previously scheduled orders from the transferred trip may end up in the waitlist, since it has become unprofitable to fulfill them and now the performer does not have time to complete them, but they cannot be assigned to another performer

Accounting for planned orders​

When planning, it is possible to take into account pre-assigned orders (based on internal business processes or previously planned) in several ways:

  1. Assign an order to a specific contractor on any shift

This case is solved through the compatibility mechanism - it is necessary to set the executor identifier for the order as the condition order.restrictions necessary for order fulfillment. This identifier must also be specified in the list of features of the performer itself performer.features.

  1. Prohibit the execution of an order by a certain contractor on any shift

This case is similar to the first one and is also solved through the compatibility mechanism, only the executor ID of the order must be blacklisted order.blacklist.

  1. Assign an order to a specific contractor on a specific shift

In this case, the order itself must be transferred not in the list of unscheduled orders orders, but directly in the list of orders assigned to a shift for a specific shift of a specific performer performer.shift.trip.waitlist.

  1. Assign an order to a specific contractor on a specific shift at a specific time

In this case, it is necessary to transfer the order itself to the field of scheduled orders in a specific trip performer.shift.trip.actions, and also fill in the location_time and order_time fields, indicating the exact times of being at the location and fulfilling the order.

An important clarification is that assigning an order to a specific time does not allow optimization of this.