Introduction
The /positions entity has access to payrollSetting (Position Payroll Settings /position-payroll-settings ) and it will reference the current active effective date delineated Employee Pay Rate (Position Pay Settings /position-pay-settings ), via one relation list that can be included (payrollSetting) and one integer for reference (payrollSetting.currentEffectivePaySettingId).
Positions
[GET] /positions/382?include=payrollSetting
{
"name": "AB Guard",
"description": "",
"customId": "UA-1",
"status": "ACTIVE",
"account": 687,
"contract": 135,
"nonBillable": false,
"shiftMemo": "",
"beginDate": "2022-08-01T00:00:00+00:00",
"endDate": null,
"breakRule": null,
"taxClass": null,
"payCodeLabel": 30,
"taxLocation": null,
"id": 382,
==> "payrollSetting": {
"payPositionRate": false,
"positionHourlyRate": null,
"holiday": "",
"holidayRate": null,
"holidayMultiplier": null,
"holidayGroup": null,
"payCode": 30,
"payBreaks": "NONE",
==> "currentEffectivePaySettingId": 397,
"id": 382
}
}As new effective pay rates enter their activation period, the ID in currentEffectivePaySettingsId will be updated.
If no effective pay rates are defined, then currentEffectivePaySettingId will be null.
Position Payroll Settings
payrollSetting can be called directly via /position-payroll-setting
[GET] /position-payroll-settings?position=382
{
"payPositionRate": false,
"positionHourlyRate": null,
"holiday": "",
"holidayRate": null,
"holidayMultiplier": null,
"holidayGroup": null,
"payCode": 30,
"payBreaks": "NONE",
"currentEffectivePaySettingId": 397,
"id": 382
}And for the current effective pay setting, its direct call is via it’s ID of 397 (this example is WITHOUT an effective dated rate, which means the basic employee rate, which by default is a date of 1970-01-01, a linux epoch value) :
Position Pay Settings
[GET] /position-pay-settings?id:in=397
{
"positionPayroll": 382,
"hourlyRateType": "EMPLOYEE",
"hourlyRate": null,
"effectiveDate": "1970-01-01T00:00:00+00:00",
"id": 397
}Next, here’s an example of the same position with a pending (to be effective as of 2024-04-11) pay rate (hourlyRate is not null, hourlyRateType is POSITION, and effectiveDate is not null):
[GET] /position-pay-settings?id:in=400
{
"positionPayroll": 382,
"hourlyRateType": "POSITION",
"hourlyRate": 17.3,
"effectiveDate": "2024-04-11T00:00:00+00:00",
"id": 400
}Positions that have a history of no effective dating, and then added effective dating for upcoming rates, you’ll see multiple records in position-pay-settings data for the same position. This is a good way of taking a look at how things have been and will become (position-pay-settings.positionPayroll == positions.id):
[GET] /position-pay-settings?positionPayroll=382
{
==> "positionPayroll": 382,
"hourlyRateType": "EMPLOYEE",
"hourlyRate": null,
"effectiveDate": "1970-01-01T00:00:00+00:00",
"id": 397
},
{
==> "positionPayroll": 382,
"hourlyRateType": "POSITION",
"hourlyRate": 17.3,
"effectiveDate": "2024-04-11T00:00:00+00:00",
"id": 400
}