Position Pay Settings / Position Payroll Settings / Effective Date

Updated July 10, 2024 14:58

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
        }

Creating an Effective Date Position Pay Setting

First you need to know the ID of the position, the hourly rate, and the date and time that the new payrate will become applicable/effective and all other previous rates ignored.

[POST] /position-pay-settings

{
            "positionPayroll": 382,
            "hourlyRateType": "POSITION",
            "hourlyRate": 17.3,
            "effectiveDate": "2024-04-11"
        }

There is constraint of uniqueness on the position’s ID and the effective date, so you can’t have two records with ID 382 and 2024-04-11.
While the field’s format will present as if it was persisted in the ISO standard time element with hour, minute or second, the validator only looks at the date portion (as should you).

“Which pay rate applies when…”

The TrackTik ecosystem is complex with how many different contexts can be set for pay rates. It’s best to consult the business rules to know which will apply in each context in addition to the notes provided earlier in this document.

https://support.TrackTik.com/hc/en-us/articles/1500001567642-HR-Payroll-Configuring-Pay-Rates

Effective Dates for rates set at the position level as described in this document are nuances that fall under bullet point #2. One of the nuances offered by a tooltip when hovering near the title “Pay Settings” in the UI suggests for example:

When employee matrix rate is specified, position pay setting will be overridden.