|
GMT time zone must be used in all references. All the date-time field values should be in the UTC format. For example, 2020-02-14T18:00:00.000Z.
|
Input Type
|
Field
|
Mandatory / Optional?
|
Description
|
Default Value/Example
|
||
---|---|---|---|---|---|---|
resources
|
workingHours
|
Mandatory
|
Business hours for the technician in a given period of the horizon.
|
Must be provided in the pairs of begin and end field values. Example: For 2 days horizon:
"workingHours": [
{
"begin": "2019-04-01T07:00:00.000Z",
"end": "2019-04-01T15:00:00.000Z"
},
{
"begin": "2019-04-02T07:00:00.000Z",
"end": "2019-04-02T15:00:00.000Z"
}
]
|
||
resourceId
|
Mandatory
|
Technician ID.
|
||||
expertise
|
Optional
|
List of skills possessed by the technician with ID, expertise level, and validity information.
• 'id' - is the skill ID and should match with the required skill on the Work Order.
• 'level' - is the expertise level of the technician and should have values in the range of 1 to 10.
• 'validFrom' and 'validTo' - are from when and till when the technician is certified with the skill. If either of the two values is empty, horizon start and end are considered respectively.
|
"expertise": [
{
"id": "skill_1", "level": 5.0,
"validFrom": "2019-07-11",
"validTo": "2020-05-19"
},
{
"id": "skill_2",
"level": 3.0,
"validFrom": "2019-07-09",
"validTo": "2021-05-19"
}
]
|
|||
efficiencyFactor
|
Optional
|
efficiencyFactor affects the service duration of the scheduled work order.
|
"efficiencyFactor": 2.0
|
|||
maxHours
|
Optional
|
Maximum hours a technician can serve in a day.
Optimizer considers lower value among workingHours or maxHour field values.
|
Example:
PT8H6M12.345S
|
|||
maxDistance
|
Optional
|
The maximum distance a technician can cover in a day.
Format: <distance_value> <unit>
|
Default value: 100 km
Example:
"maxDistance": "200 km"
|
|||
geoLocation
|
Mandatory if there is no address.
|
Start address of the technician (it can be home) (in latitude-longitude pair values).
Note: Either geoLocation or address values are mandatory. If one is present, then the other optional. If both values are present, then geolocation has precedence over address.
|
Example:
"geoLocation": {
"latitude": "37.787514",
"longitude": "-122.39905"
}
|
|||
address
|
Mandatory if there is no geolocation.
|
Start address of the technician (it can be home).
Format: Comma-separated Street, City, State, Zip, Country
Note: Either geoLocation or address values are mandatory. If one is present, then the other optional. If both values are present, then geolocation has precedence over address.
|
Example:
Jersey, 145 2nd St, San Francisco, California 94105, United States of America
|
|||
currentGeolocation
|
Optional
|
The current geolocation of the technician.
The following is a format example:
{ "latitude": "38.275612", "longitude": "-122.668396" }
|
• These fields are supported only when:
◦ The Optimize for Single Day option is enabled in the dispatch process.
◦ All the technicians have single-day working hours.
• If one of the field values is present, the other field value is optional. If both values are present, the currentGeolocation field value has precedence over the address.
|
|||
currentAddress
|
Optional
|
The current address of the technician.
Format: Comma-separated Street, City, State, Zip, Country
|
||||
travelUnitCost
|
Optional
|
Travel cost per unit for the technician.
|
The default value is 1.
|
|||
overTimeTolerance
|
Optional
|
Technician overtime tolerance limit.
Format: PT<h>H<m>M<s>S
Where h is for hours, m for minutes, and s for seconds.
All values are not needed.
If only hours to be passed: PT2H
If hours and minutes to be passed: PT1H30M
If only minutes to be passed: PT45M
|
The default value is 0.
Example: “PT30M”
|
|||
overNightStay
|
Optional
|
• ‘isPolicyOverRidesEfficiency’ - It is used for overnight stay decisions.
• ‘thresholdDuration’ - ThresholdDuration for overnight stay.
• ‘thresholdDistance’ - ThresholdDistance for overnight stay.
• ‘totalStaysOut’ – Maximum number of overnight stays a technician can make in a cycle.
• ‘staysOutInRow’ - Maximum number of consecutive days a technician can stay overnight.
• ‘minRecoverHours’ - Minimum number of days to recover after 'staysOutInRow’ is reached before the next overnight stay can be scheduled.
• ‘startOfTheWeek’ - The first day of the week used to calculate the cycle.
• ‘cycleOfTheWeek’ – Number of days which makes the period.
|
"overNightStay": {
"isPolicyOverRidesEfficiency": true,
"thresholdDuration": "PT10H",
"thresholdDistance": "500.0 km",
"totalStaysOut": "5",
"staysOutInRow": "4",
"minRecoverHours": "8",
"startOfTheWeek": "2019-07-11",
"cycleOfTheWeek": "7"
}
|
|||
hourlyCost
|
Optional
|
The hourly cost of the technician.
|
The default value is 60.
|
|||
fixedCost
|
Optional
|
Fixed cost of the technician.
|
The default value is 0.
|
|||
avgTravelSpeed
|
Optional
|
Average travel speed of the technician.
Format: <speed_value> <unit>
|
The default value is 60 km/h.
Example:
"40 km/h"
|
|||
driveBeforeShiftStart
|
Optional
|
Maximum duration before start of working hours where the technician should drive in own time.
|
Default value: PT0H
Example: PT3H
|
|||
workOrders
|
workOrderId
|
Mandatory
|
Mandatory Work Order ID.
|
|||
serviceDuration
|
Mandatory
|
Service duration for the work order.
Format: PT<h>H<m>M<s>S
Where h is for hours, m for minutes, and s for seconds.
All values are not needed.
If only hours to be passed: PT2H
If hours and minutes are to be passed: PT1H30M
If only minutes to be passed: PT45M
|
Example: PT2H
|
|||
preferredStart
|
Optional
|
Preferred start date and time to take up this work order. This comes from the SLA of the work order.
Format: UTC.
Note: If the access hours and the preferredStart times do not intersect, the work order will not qualify for scheduling.
|
Example:
"2019-07-19T17:30:00.000Z"
|
|||
preferredEnd
|
Optional
|
Preferred end date and time to take up this work order. This comes from the SLA of the work order.
Format: UTC.
|
Example:
"2019-07-21T16:00:00.000Z"
|
|||
accessHours
|
Mandatory
|
Access hours of the work order for the given Horizon.
Must be provided in the pairs of begin and end field values.
|
Example for 2 days horizon:
"accessHours": [
{
"begin": "2019-04-01T07:00:00.000Z",
"end": "2019-04-01T15:00:00.000Z"
},
{
“begin”: "2019-04-02T07:00:00.000Z",
"end": "2019-04-02T15:00:00.000Z"
}
]
|
|||
requiredExpertise
|
Optional
|
List of required skills to service the Work Order with minimum level. Also mentions whether the skill is mandatory or not.
• ‘id’ – Skill and Id should match skill of the technician.
• ‘level’ – Minimum expertise required by technician to service this Work Order. Level ranges between 1 to 10.
• ‘isOptional’ – Defines if the skill populated is mandatory or not. If mandatory, only technicians with the skill and minimum expertise level are scheduled.
|
"requiredExpertise": [
{
"id": "skill_1",
"level": 3.0,
"isOptional": false
},
{
"id": "skill_2",
"level": 3.0,
"isOptional": true
}
]
|
|||
recommendedResources
|
Optional
|
List of qualified technicians for the work order.
If this field is populated with the list of qualified technicians for the work order, the most suitable out of the listed technicians will be assigned to the work order. If this field is empty, then any of the available technicians will be assigned to the work order.
|
"recommendedResources": [
{
"id": "Tech-1",
"priority": "5"
}
]
|
|||
mandatoryResources
|
Optional
|
List of mandatory resources to service the WO.
• ‘id’ – Technician ID
• ‘priority’ – Preference to pick a particular technician over others in the list. Also, Technicians can be prioritized manually.
|
"mandatoryResources": [
{
"id": "44aaa753-fd03-43dc-9ad5-0ebd22e0f470",
"priority": 4.0
}
]
|
|||
bannedResources
|
Optional
|
List of resources who are not assigned to any work orders.
|
"bannedResources": [
{
"id": "cc524c74-3382-43fe-812c-aee3a6747e78",
"priority": 4.0
}
]
|
|||
assignedResourceId
|
Optional
|
The currently assigned technician ID that needs to be honored in case of a Fixed work order schedule. For other work orders (which are optimizable), this field has no relevance. Instead, use the recommendedResources field to mention the assigned resource if it needs to be considered in future runs.
Note: This field is mandatory if you have specified the LOCK_IN_PLACE option in the lockschedule field for the work order.
|
“assignedResourceId”: “Tech1”
|
|||
geoLocation
|
Mandatory if there is no address.
|
Geolocation of the work order (in latitude-longitude pair values).
Note: Either geoLocation or address values are mandatory. If one is present, then the other optional. If both values are present, then geolocation has precedence over address.
|
Example
" geoLocation ": {
"latitude": "37.787514",
"longitude": "-122.39905"
}
|
|||
address
|
Mandatory if there is no geoLocation.
|
Address of the work order.
Format: Comma-separated Street, City, State, Zip, Country
Note: Either geoLocation or address values are mandatory. If one is present, then the other optional. If both values are present, then geolocation has precedence over address.
|
Example:
Jersey, 145 2nd St, San Francisco, California 94105, United States of America
|
|||
lockSchedule
|
Optional
|
This field is used to lock the work order. The value indicates how the work order is locked.
Possible values:
• LOCK_IN_PLACE: Fixed arrival time and the assigned technician.
• LOCK_ARRIVAL_TIME: Fix arrival time but not technician. An optimal technician will be chosen in case there is a change in optimization data. This option is chosen when the “Appointment Type” field in the work order is null.
• LOCK_ARRIVAL_WINDOW: Fix the arrival time within an arrival window. This option allows when the “Appointment Type” field in the work order has a value.
When any capacity or reservations are chosen, accessHourspecified or the work order should match with this. There should be only one pair of accessHours for this work order. If there are multiple pairs of data in the accessHours input element, then the work order will not be considered for scheduling by the optimizer and it will throw an error scenario.
If you have chosen LOCK_IN_PLACE or LOCK_ARRIVAL_TIME, the initial value of the accessHours value pair is considered as the start time for the work order.
If you have chosen LOCK_ARRIVAL_WINDOW, the work order will be scheduled to start within the time frame of the accessHours value pair (begin and end time fields).
|
In the sample input file, see WO-00305987 which has lockschedule field value specified.
|
|||
importance
|
Mandatory
|
Importance of the work order.
Format: Integer
|
The default value is 1.
The recommended value range is 1-10, where 1 is the lowest value and 10 is the highest value.
|
|||
nodeColor
|
Optional
|
The capacity reservation rule associated with the job.
|
||||
isAvailableForOvernightStay
|
Optional
|
Boolean to flag if the technician can make an overnight stay at the Work Order location or not.
|
"isAvailableForOvernightStay": true
|
|||
applyEfficiencyFactor
|
Optional
|
Boolean to indicate whether technician efficiency factor calculation should apply for this Work Order or not.
|
"applyEfficiencyFactor": true
|
|||
events
|
eventId
|
Mandatory
|
Event identifier that can be a work order or non-work order event.
|
|||
eventDuration
|
Mandatory
|
Visit duration of the event.
Format: PT<h>H<m>M<s>S
Where h is for hours, m for minutes, and s for seconds.
All values not needed.
If only hours to be passed: PT2H
If hours and minutes to be passed:PT1H30M
If only minutes to be passed: PT45M
|
Example:
“eventDuration”: “PT3H”
|
|||
assignedResourceId
|
Mandatory
|
Technician ID attached to the non-work order event.
|
||||
accessHours
|
Mandatory
|
Service times for the fixed technician event.
It must be noted that the eventDuration should fit within the access hours in case of non-flexible fixed events, else it may shuffle within the accessHours. If the accessHours span is lesser, then the eventduration, then it’s an invalid input.
Must be provided in the pairs of begin and end field values.
|
Example:
"accessHours": [
{
"begin": "2019-04-01T07:00:00.000Z",
"end": "2019-04-01T15:00:00.000Z"
}
]
|
|||
eventType
|
Mandatory
|
Defines if the event should be considered for geolocation optimization.
Values: CALENDAR_ITEM, CALENDAR_GEO_ITEM
In case of CALENDAR_ITEM is passed, the geolocation/address won’t be considered.
If the CALENDAR_GEO_ITEM is passed, it is mandatory to have the address/geolocation, else it will be considered invalid input.
|
||||
geoLocation
|
Mandatory if eventType is CalendarGeoItem, else it is optional.
|
GeoLocation of the event (in latitude-longitude pair values).
|
Example:
" geoLocation ": {
"latitude": "37.787514",
"longitude": "-122.39905"
}
|
|||
address
|
Mandatory if eventType is CalendarGeoItem and geoLocation is blank, else it is optional.
|
Address of the event.
Format: Comma separated Street,City,State,Zip,Country
|
Example:
Jersey, 145 2nd St, San Francisco, California 94105, United States of America
|
|||
nodeColors
|
id
|
Optional
|
The capacity reservation rule ID.
|
Example: 1000
|
||
colorName
|
Optional
|
The capacity reservation rule name.
|
Example: PreventiveMaintenance
|
|||
percentage
|
Optional
|
The capacity reservation percentage for the specified rule.
|
Example: 20.0
|
|||
parameters
|
distanceProvider
|
Mandatory
|
The mode used for distance matrix calculation. Supported values are:
• Haversine: Uses haversine algorithm to calculate distances between locations.
• MapProvider: Uses default map provider. If mapProviderKey parameter also passed, uses Google map provider with provided API key.
|
MapProvider
|
||
mapProviderKey
|
Optional
|
The Google API key.
|
||||
modeOfTravel
|
Mandatory
|
Mode of technician travel.
|
Driving
|
|||
objectiveTimeWindow
|
Optional if you have not selected Custom as value for objectiveProfileName.
|
This indicates how important it is for your organization to meet time windows and appointments.
|
Supported value(s): 0 to 100
|
|||
objectiveDistance
|
This indicates how important it is for your organization to minimize travel costs.
|
Supported value(s): 0 to 100
|
||||
objectiveTime
|
This indicates how important it is for your organization to minimize overtime costs.
|
Supported value(s): 0 to 100
|
||||
objectiveRelation
|
This indicates how important it is for your organization to send the preferred technician for the work order.
|
Supported value(s): 0 to 100
|
||||
objectiveWorkDistribution
|
This indicates how important it is for your organization to assign jobs to deliver the service as quickly as possible and to meet the SLAs.
|
Supported value(s): 0 to 100
|
||||
objectiveProfileName
|
Optional
|
Thi is the objective to be selected to fine-tune the relative cost/weight of various factors that influence the choice of the technician for a work order, and also the appropriate slot in the technician’s calendar.
|
Supported value(s):MAXIMIZE_SLA_COMPLIANCE, MAXIMIZE_RESOURCE_UTILIZATION, CUSTOM
|