Task Site Instructions are for contracts with a dispatch element where you need to define things like site, billing model, SLA . In the web application it looks like:
Task Site Instructions contains a high amount of relations to dispatch and billing, which means price tier, bill item, and task price tier. Within Price Tier is the relation to the Contract as well. That means that to work with this endpoint a lot of data dependencies need to exist first:
- Client Site
- Contract
- Bill Item
- Task Type (Job Type)
- Billable Item
- Task Price Tier
In general the endpoint will be difficult to work with without a LOT of TrackTik business domain knowledge and its web application in general. You'll be best served aligning with an administrator of a TrackTik portal to align the UI based data configuration with the goals of your back-end solution.
A basic Task Site Instruction record contains:
{
"taskType": 51,
"site": 687,
"jobInstructions": "",
"generalInstructions": "",
"checkPointTour": null,
"taskPriceTier": 187,
"dispatchSla": 112,
"generalDispatchSla": "",
"gracePeriodRunsheetStart": 2,
"gracePeriodRunsheetEnd": 2,
"gracePeriodSiteTaskStart": null,
"gracePeriodSiteTaskEnd": null,
"allowClientRequest": false,
"id": 137
}But with a few inclusions of the relation lists, you get a fully picture as to its complexity:
[GET] /task-site-instructions/137?include=taskType,taskType.billableItem,taskPriceTier.contract
{
"site": 687,
"jobInstructions": "from jobInstructions: Once on site, make sure to....xyz ",
"generalInstructions": "",
"checkPointTour": null,
"priceTier": 187,
"dispatchSla": 112,
"generalDispatchSla": "",
"gracePeriodRunsheetStart": 2,
"gracePeriodRunsheetEnd": 2,
"gracePeriodSiteTaskStart": null,
"gracePeriodSiteTaskEnd": null,
"allowClientRequest": false,
"id": 137,
"taskPriceTier": {
"customId": "",
"name": "Randa Test",
"billItem": 4,
"taxClass": null,
"chargeType": "PREPAID",
"serviceModel": "DISPATCH_SERVICE_MODEL",
"rate": 150,
"rateMatrix": null,
"instructions": "",
"effectiveDate": "2024-05-16T00:00:00+00:00",
"validUntilDate": null,
"cancellationThresholdInMinutes": null,
"account": 867,
"discount": 0,
"fuelSurcharge": null,
"holiday": "",
"holidayGroup": null,
"holidayMultiplier": null,
"holidayRate": null,
"holidayFlatRate": null,
"id": 187,
"contract": {
"customId": "60685_2320000157",
"account": 687,
"billingFrequency": "MONTHLY",
"billingFrequencyType": "ON_END",
"billingStartDate": "2024-04-01T00:00:00+00:00",
"semiMonthlyFirstReferenceDay": null,
"semiMonthlySecondReferenceDay": null,
"invoiceDayToAdd": 0,
"name": "FPS LA Non SSA",
"paymentMethod": 4,
"paymentTerms": "DAYS_30",
"externalId": "",
"proposalNumber": "",
"estimatedPerPeriodRevenue": 0,
"serviceStartDate": "2024-04-01T00:00:00+00:00",
"serviceEndDate": null,
"status": "ACTIVE",
"type": "CONTRACT",
"contractedHours": 8,
"contractedHoursSchedule": "WEEKLY",
"id": 148
}
},
"taskType": {
"id": 51,
"name": "Alarm Response",
"prefix": "ALM",
"details": "Respond to Alarm Service",
"defaultLanguage": "",
"translatable": false,
"reportTemplate": 2818,
"dispatchable": true,
"workflow": 2,
"priority": "URGENT",
"dispatchGroup": "ZONE_USERS",
"billable": "REQUIRE_CONTRACT",
"schedulableRunsheet": true,
"schedulableSiteTask": false,
"isFlagDay": false,
"active": true,
"isGlobal": false,
"region": 5,
"forCtaConfig": false,
"billableItem": {
"name": "Alarm Response ",
"customId": "AR-D1",
"status": "ACTIVE",
"isGlobal": false,
"region": 5,
"id": 19
}
}
}The data validation is a bit light with this endpoint, so be sure to validate the IDs of your relations just to play it safe. You can accidentally assign a contract that doesn't belong to the Client Site for example.
The Dispatch Billing Model of the UI is defined by the taskPriceTier. The taskPriceTier must contain a relation to the Contract for the Site defined in the list of the panel.
The Alarm SLA of the UI is defined by the dispatchSla.
When you set the jobInstructions value, it will be presented in the UI when creating a new Dispatch Task like this: