Synchronous (solve, evaluate, suggest) operation for low latency results

Synchronous

Type of break that can be defined for a resource

Options to manage the explanation of the solution

When enabled the explanation will contain a map of all the alternative positions for each job

When true the map of alternative positions will contain only feasible alternatives

Job-1

List of vehicle names that are allowed to be assigned to this order.

When a job is performed at the same location as another job, `durationSquash` ensures that the 2nd job' service time is reduced to this value. Example: `duration=600` and `durationSquash=30` means that the 2nd job will only take 30 seconds to perform.

In the case of partialPlanning planning, this indicates whether this order should be integrated into the planning or not.

In the case of partialPlanning planning, this indicates the weight of this order.

Warm start for the arrival time. Use this to speed up the solver and to start from an initial solution.

Warm start for the assigned resource: name of the vehicle to which this job is planned. Use this to speed up the solver and to start from an initial solution.

Padding time before and after the job. In seconds

Planned arrival time The second of day at which the order is planned to complete. The difference with the actual arrival time is scaled in the score with plannedWeight.

Fixed date on which this order is already planned and should hence be taken into account in the planning.

Name of the resource to which this order is already planned and should hence be taken into account in the next planning.

Priority of the job will ensure that it is included in the planning over other lower priority jobs. We evaluate the priority multiplied with the duration of the job. The higher the priority, the more likely it is that the job will be included in the planning. Defaults to 1.

Rankings define resource preferences for this job, where lower values indicate stronger preference for specific resources.

Enables job interruption by resource unavailability breaks. When true, the job can start before a break, pause during the break, and resume afterward. Default: false.

Urgency of the job will ensure that it is likely to be scheduled before jobs with a lower urgency.

List of start/end date/time combinations.

Use euclidian distance for travel time. Default false.

If true, the workload (service time) will be spread over all days of one resource. (interacts with `Weights.workloadSpreadWeight` and `options.workloadSensitivity`)

If true, the workload (service time) will be spread over all resources and all days. (interacts with `Weights.workloadSpreadWeight` and `options.workloadSensitivity`)

If the request is submitted to the suggestion end point it indicates the maximum number of suggestions the solver should return (default is 0 which means return all)

Minimise the vehicle useage or minimise total travel time. Two different objective functions.

If the request is a suggestion then if the initial plan is feasible the solver will return only feasible suggestions otherwise it will return only suggestions that do not worsen the infeasibility  (default is true)

We will try to assign as many jobs as possible and create a partial schedule unless `partial` is set to `false`. Default set to true. 

Let our map server calculate the actual polylines for connecting the visits. Processing will take longer.

The routing engine to be used. Choose between OpenStreetMaps (OSM), TomTom or Google.

The smallest steps in arrival time to which results will be snapped. The snapping policy is round-up and is used at runtime, implying it influences the score calculation. Unless a post-calculation feature such as order padding is used, any calculated arrival time in `[391, 395]` with a `snapUnit` of `5` will yield `395`. Fallback value for `Options.use_snapUnit_for_waitRange`.

Modifier to travel time for traffic. If you want actual traffic information, use HERE or TomTom map integration.

A ranking is a measure of the affinity of a `Resource` towards a `Job`.

certified-technician

Resource ranking for this tag (1-100). Lower ranking means more preferred resource. When a job is assigned to a resource, the score is penalised based on the ranking.

List of job names. This can be sequence dependent.

Maximum seconds between two jobs in a SEQUENCE relation.

In case of a `SAME_TIME` relation, the maximum waiting time in seconds between the jobs. Defaults to `1200` seconds or `20` minutes.

Minimum seconds between two jobs in a SEQUENCE relation.

Allows the solver to plan a subset of the jobs in the job relation when overconstrained

Determines if the time interval between jobs in the relation should be considered from the arrival time or from the departure time. Default setting set time intervals to start from the arrival time.

Specifies the type of relation. It must be either of type `SAME_TRIP`, `SEQUENCE`, `DIRECT_SEQUENCE` or `NEIGHBOR`.

vehicle-1

End location (deprecated: use resource.shifts[].end)

Financial cost per hour per resource. Only calculated when working (driving, servicing or waiting)

Region of the resource. The solver will minimise the euclidean distance of every stop to this region location.

Shift definition of a Resource over course of planning period

Start location (deprecated: use resource.shifts[].start)

The routing engine to use for distance and travel time calculations

Maximum work time in seconds. Work time is service time + drive/travel time.

Minimum work time in seconds. Work time is service time + drive/travel time.

Period of the rule. If null, then it encompasses the entire period.

Shift definition. Every potential shift of a resource should be defined here. Every shift can be a trip.

Ignore the travel time from the last order to the optional end location

Ignore the travel time from the start location to the first order

Determines if the time interval between jobs should be measured from arrival or departure

Weight modifier for the resources allowed constraint.

Weight modifier scheduling jobs as soon (on day basis) as possible.

Weight modifier for the drive time constraint.

Weight modifier for minimizing activating another resource on a day trip. The weight is put on the same balance as travel time. So setting this weight to 3600 (1hour) will make sure that the solver will try to minimize the number of resources used on a day trip compared to 1 extra hour of travel time.

Weight modifier for planned vehicle and planned date requirement.

Weight modifier for `job.priority` that ensures that priority orders are scheduled. Note that this does not make sure that they are scheduled sooner.

Weight modifier for tag ranking preference. Higher weight increases the importance of assigning jobs to higher-ranked resources.

Solvice Platform

VRP API

Synchronous

Authorizations

Path Parameters

Query Parameters

Body

Response