- Products ProductsLocation Services
Solve complex location problems from geofencing to custom routing
PlatformCloud environments for location-centric solution development, data exchange and visualization
Tracking & PositioningFast and accurate tracking and positioning of people and devices, indoors or outdoors
APIs & SDKsEasy to use, scaleable and flexible tools to get going quickly
Developer EcosystemsAccess Location Services on your favorite developer platform ecosystem
- Documentation DocumentationOverview OverviewServices ServicesApplications ApplicationsDevelopment Enablers Development EnablersContent ContentHERE Studio HERE StudioHERE Workspace HERE WorkspaceHERE Marketplace HERE MarketplacePlatform Foundation and Policy Documents Platform Foundation and Policy Documents
- Pricing
- Resources ResourcesTutorials TutorialsExamples ExamplesBlog & Release Announcements Blog & Release AnnouncementsChangelog ChangelogDeveloper Newsletter Developer NewsletterKnowledge Base Knowledge BaseFeature List Feature ListSupport Plans Support PlansSystem Status System StatusLocation Services Coverage Information Location Services Coverage InformationSample Map Data for Students Sample Map Data for Students
- Help
Tour Planning Billing
Tour Planning is a premium product and its billing is different than for the other HERE APIs/services. It is calculated on the basis of the number of transactions, and it is described in details below in this tutorial. Check the Tour Planning pricing plan on the pricing page.
The usage of Tour Planning is billed based on the number of transactions. The transactions are calculated depending on the number of locations that were set in the tour planning problem. In other words, each location specified in the problem (vehicle shift start and end locations, vehicle break location if specified, job pick up/ delivery locations) is counted in billable transactions. Billable transactions are only generated for the Vehicle Routing Problems that are well formulated. If a problem was built incorrectly and returned an error as a response, the transactions are not billed. At the same time, for the asynchronous endpoint, the transactions are added even if the user has not requested the solution of the problem after the solution is available. Below we consider some examples of how your problem may be billed regarding the number of those transactions.
Considering the above, we need to understand that in terms of the fleet constraints, we will calculate the vehicle shift start and end location, all the shifts’ locations when we use multiple shifts, and all the locations of the breaks as the transactions. Regarding the Plan part of the problem, all the single and multi jobs locations, and all the jobs’ locations added when replanning the tour will be calculated as transactions.
Let's have a look at the problem below. Here we have 1 vehicle that is intended to execute 4 jobs. The vehicle has shift start and end locations - so, those locations are calculated as 2 transactions. Each of the jobs here has 1 location, so those locations will be calculated as 4 transactions. Note that additionally, the example problem has relations set for the vehicle to execute some of the jobs in the specific order, but this option doesn't change the number of transactions as it doesn't add or remove any locations to the problem. Eventually, the example problem will be optimized into a tour with 6 locations, hence 6 transactions.
{
"fleet": {
"types": [
{
"id": "Vehicle_1",
"profile": "car_1",
"costs": {
"fixed": 9.0,
"distance": 0.004,
"time": 0.005
},
"shifts": [
{
"start": {
"time": "2021-08-27T08:03:00Z",
"location": {
"lat": 52.530971,
"lng": 13.384915
}
},
"end": {
"time": "2021-08-27T18:03:00Z",
"location": {
"lat": 52.530971,
"lng": 13.384915
}
}
}
],
"capacity": [
10
],
"limits": {
"maxDistance": 300000,
"shiftTime": 43200
},
"amount": 1
}
],
"profiles": [
{
"type": "car",
"name": "car_1"
}
]
},
"plan": {
"jobs": [
{
"id": "job_1",
"tasks": {
"deliveries": [
{
"places": [
{
"times": [
[
"2021-08-27T09:03:00Z",
"2021-08-27T18:03:00Z"
]
],
"location": {
"lat": 52.59175589353722,
"lng": 13.350747750372257
},
"duration": 360
}
],
"demand": [
1
]
}
]
}
},
{
"id": "job_2",
"tasks": {
"deliveries": [
{
"places": [
{
"times": [
[
"2021-08-27T11:03:00Z",
"2021-08-27T20:03:00Z"
]
],
"location": {
"lat": 52.43363386232821,
"lng": 13.403232562191313
},
"duration": 540
}
],
"demand": [
1
]
}
]
}
},
{
"id": "job_3",
"tasks": {
"deliveries": [
{
"places": [
{
"times": [
[
"2021-08-27T10:03:00Z",
"2021-08-27T16:03:00Z"
]
],
"location": {
"lat": 52.473321658918245,
"lng": 13.28972099097991
},
"duration": 660
}
],
"demand": [
1
]
}
]
}
},
{
"id": "job_4",
"tasks": {
"deliveries": [
{
"places": [
{
"times": [
[
"2021-08-27T09:03:00Z",
"2021-08-27T17:03:00Z"
]
],
"location": {
"lat": 52.54165532725351,
"lng": 13.365047170290309
},
"duration": 1140
}
],
"demand": [
1
]
}
]
}
}
],
"relations": [
{
"type": "sequence",
"jobs": [
"job_1",
"job_4"
],
"vehicleId": "Vehicle_1_1"
}
]
}
}
When using Multiple Shifts, each of the shift start and end locations, even if they are the same, will be calculated as a transaction. In the example below we have a vehicle with 4 different shifts set:
- Shift 1:
2021-10-23T09:00:00Z-2021-10-23T12:00:00Z - Shift 2:
2021-10-24T09:00:00Z-2021-10-24T12:00:00Z - Shift 3:
2021-10-25T09:00:00Z-2021-10-25T12:00:00Z - Shift 4:
2021-10-26T09:00:00Z-2021-10-26T12:00:00Z
Those shifts' start and end locations are the same, as the driver obviously starts and ends his/her shifts in the same depot. However, the algorithm will calculate each of the locations as a new transaction, so in the example below we will have 8 transactions totally in the fleet section.
{
"fleet": {
"types": [
{
"id": "Vehicle_1",
"profile": "car",
"costs": {
"fixed": 10.0,
"distance": 0.002,
"time": 0.003
},
"shifts": [
{
"start": {
"time": "2021-10-23T09:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
},
"end": {
"time": "2021-10-23T12:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
}
},
{
"start": {
"time": "2021-10-24T09:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
},
"end": {
"time": "2021-10-24T12:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
}
},
{
"start": {
"time": "2021-10-25T09:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
},
"end": {
"time": "2021-10-25T12:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
}
},
{
"start": {
"time": "2021-10-26T09:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
},
"end": {
"time": "2021-10-26T12:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
}
}
],
"capacity": [
10
],
"amount": 1
}
],
"profiles": [
{
"type": "car",
"name": "car"
}
]
},
When using Breaks set for the vehicle, you should note that the break is considered a transaction only if the location is given for the break. If the location for the break is not set, then the break happens at one of the job locations. So, there is no extra transaction for the break in this case. In the example below we have a vehicle with the fixed shift and a break. The shift start and end locations are obviously equal to the transactions, and the break has no location. So in the fleet constraints for this example we have 2 transactions.
{
"fleet": {
"types": [
{
"id": "92d3cd5cca04",
"profile": "car_1",
"costs": {
"fixed": 10.0,
"distance": 0.004,
"time": 0.009
},
"shifts": [
{
"start": {
"time": "2021-08-27T08:03:00Z",
"location": {
"lat": 52.530971,
"lng": 13.384915
}
},
"end": {
"time": "2021-08-27T17:03:00Z",
"location": {
"lat": 52.530971,
"lng": 13.384915
}
},
"breaks": [
{
"duration": 1800,
"times": [
[
"2021-08-27T12:03:00Z",
"2021-08-27T13:03:00Z"
]
]
}
]
}
],
"capacity": [
2
],
"limits": {
"maxDistance": 300000
},
"amount": 1
}
],
"profiles": [
{
"type": "car",
"name": "car_1"
}
]
},
When using Multi-Jobs with several pickups and deliveries within, logically we will calculate each of those pickups and deliveries locations as separate transactions. Let's say, if we had a multi-job with 3 pickups and 1 delivery, to deliver all those pickups to one location, like in the example below, then those constraints' calculation would give us 4 transactions in total.
"plan": {
"jobs": [
{
"id": "job_1",
"tasks": {
"pickups": [
{
"places": [
{
"location": {
"lat": 52.47706593757918,
"lng": 13.390815701172201
},
"duration": 660,
"tag": "Address_1"
}
],
"demand": [
1
]
},
{
"places": [
{
"location": {
"lat": 52.473571009931106,
"lng": 13.389035169086807
},
"duration": 1140,
"tag": "Address_2"
}
],
"demand": [
1
]
},
{
"places": [
{
"location": {
"lat": 52.53090538774364,
"lng": 13.384692097156309
},
"duration": 840,
"tag": "Address_3"
}
],
"demand": [
1
]
}
],
"deliveries": [
{
"places": [
{
"location": {
"lat": 52.58919138279804,
"lng": 13.462161100698735
},
"duration": 1020,
"tag": "Address_4"
}
],
"demand": [
3
]
}
]
}
}
]
}
}
When using Alternative Locations, assume that all the locations specified in the problem constraints will be calculated as transactions, even though the vehicle will not visit all of them after the solution is generated.
The alternative locations are set for a job with the specific time windows for each location. That means that after the solution is calculated, the vehicle will visit only one of those locations, the one that was determined as the optimal by the solver. When the problem is formulated, all the locations added in the constraints will be calculated as transactions.
In the example below, we have a job with two locations tagged as Home and Work set for the different time windows. Even though after the solution will be calculated including only one of them in the tour, the number of transactions here will still remain 2.
"plan": {
"jobs": [
{
"id": "Job_1",
"tasks": {
"pickups": [
{
"places": [
{
"times": [
[
"2021-10-23T08:30:00Z",
"2021-10-23T09:00:00Z"
]
],
"location": {
"lat": 52.5154509,
"lng": 13.4216700
},
"duration": 1150,
"tag": "Home"
},
{
"times": [
[
"2021-10-23T10:00:00Z",
"2021-10-23T19:00:00Z"
]
],
"location": {
"lat": 52.6834366,
"lng": 13.2781471
},
"duration": 1150,
"tag": "Work"
}
],
"demand": [
1
]
}
]
}
},
