Scenario
Imagine an employee who received training, and should get paid for their time.
Also imagine that not all TrackTik users have the scheduling module, therefore a more direct billing route is recommended.
An ad hoc payment, on the other hand, isn’t tied to shifts/the live schedule. These ad hoc payments can be logged against an employee & account, for a specific payrollCode/quantity/rate, and are tied to an ‘event date’. They can also have a ‘memo’ attributed. These adhocs are then processed when a payroll batch gets processed. It seems to be a ‘cleaner’ approach that doesn’t need to get ‘mixed in’ with actual shifts and schedules. The developer would need to know the correct account ID and payrollCode ID to send through (which would vary for each client):
POST to /payroll-adhocs
Creation of a new ‘ad hoc’ via the API, as per the above, would have the ad hoc appear under the employee’s HR profile with a ‘pending payroll’ status:
So, the above example would represent 3 hours (‘quantity’) at $23 (‘rate’) and is tied to a custom paycode (in this case, TRAIN). It would then be processed/approved during the next payrun generation.
Important to note that TrackTik doesn’t actually process any payments, either – the client would still need to export the payrun data from TrackTik and enter/import it into their payroll provider as usual.
Sample Data from API
{
"isOvertimeWeighted": true,
"id": 30,
"account": 12,
"employee": 1269,
"payrollCode": 22,
"memo": "233",
"eventDate": "2023-02-20T00:00:00+00:00",
"quantity": 1,
"rate": 23
},
{
"isOvertimeWeighted": false,
"id": 31,
"account": 33,
"employee": 1052,
"payrollCode": 21,
"memo": "Covered Paul shift",
"eventDate": "2023-03-14T00:00:00+00:00",
"quantity": 8,
"rate": 10
},
{
"isOvertimeWeighted": false,
"id": 32,
"account": 687,
"employee": 1442,
"payrollCode": 3,
"memo": "test",
"eventDate": "2024-03-18T00:00:00+00:00",
"quantity": 1,
"rate": 12
}