GRIA Working Days and Weekends Compliance

Note: This integration is an extension that is developed outside the normal release schedule to meet specific customer needs. To request one of these extensions, you must submit a Salesforce Service Request to UKG. After the extension is delivered to your tenant, you can edit it accordingly.

The GRIA (General Retail Industry Award) Working Days and Weekends Compliance extension automatically applies penalty pay when an employee's actual hours violate specified scheduling rules.

Australian retailers must follow specific rules and regulations that outline employment conditions. These rules and regulations are described in the GRIA or the organization’s specific Enterprise Agreement.

The extension focuses on GRIA rules, such as:

  1. Regular Sunday Workers

  2. Consecutive Days Off with Weekend

  3. Consecutive Days Off 2+2 or 3

  4. Maximum Working Days

Combinations of GRIA rules are associated with schedule rule sets. When assigned to employees, the schedule rule sets initiate GRIA rule validation. The same GRIA rule combination applies to multiple schedule rule sets by the use of wildcards.

Employees maintain the right to opt out of GRIA regulations entirely or partially, by using an MVA (Mutual Variation Agreement) to waive certain rules. Assign those employees a different schedule rule set that aligns with their MVA.

The extension cascades through all enabled GRIA rules, using actual totals in conjunction with historical corrections for the evaluation. Penalty pay is assigned in the timecard using a work rule transfer that overrides the employee’s active work rule.

Penalty pay work rules are configured according to customer requirements. Configurations, such as specific overtimes, premium zones, and bonuses, are considered.

For example, the extension is configured to identify the penalty work rules with a suffix, such as -GRIA-PenaltyPay.

If the employee's work rule on a day is called AU-RET30, and penalty pay is initiated, the extension will look for AU-RET30-GRIA-PenaltyPay and use this work rule in a transfer.

When no corresponding penalty work rule is found, no transfer is applied.

A comment and note applied to the work rule transfer provides information about the validation period, the original and override work rules, and the name of the violated GRIA rule.

When combining multiple GRIA validations in the same rule set, the system sequentially processes all enabled GRIA rules, from Rule 1 to Rule 4. As a result, the outcome of a previous rule violation is considered when validating the next rule. This means that once a worked day receives penalty pay, it is considered a day off for all of the subsequent rule validations. Employees are prevented from receiving double penalty pay, otherwise known as double dipping.

Rule 1 — Regular Sunday Workers

Qualification

This rule applies to the employee who qualifies as a regular Sunday worker and validates whether the employee had a 3-day weekend off during a 4-week evaluation period.

The 3-day weekend off implies that the employee must be off on both weekend days plus an adjacent weekday. For example, Friday+Saturday+Sunday or Saturday+Sunday+Monday.

To qualify as a regular Sunday worker, the extension checks worked Sundays in the timecard and cascades through the following validations:

  1. Looks back at the last 52 Sundays, and if 26 or more were worked, the employee qualifies.

  2. When not yet qualified, looks back at the last 34 Sundays, and if 17 or more were worked, the employee qualifies.

  3. Finally, looks back at the last 12 Sundays, and if 8 or more were worked, the employee qualifies.

Anchor point for Sunday worker qualification

The extension begins with the last complete weekend in the 4-week validation period when it evaluates the number of worked Sundays.

For example, the extension runs on Friday, March 31, 2023. The last complete weekend during March 2023 is March 26-27.

All Sundays that fall between March 26 and January 8 (12 weeks earlier) are evaluated, and if 8 or more were worked, the employee qualifies as a regular Sunday worker for that validation period.

Penalty pay

When the employee qualifies as a regular Sunday worker and the free weekend rule is violated, the extension creates a 3-day weekend equivalent by assigning penalty pay on a worked day. The extension applies one of the following options, cascading from the least expensive option 1 (single day penalty) to the most expensive, option 3 (multiple days penalty).

Option 1 — Find a full weekend off and assign penalty pay to 1 adjacent worked day to create the 3-day weekend. When multiple options exist, the system processes chronologically.

Option 2 — Find a partial weekend off and assign penalty pay to 1 weekend day and 1 adjacent weekday to create the 3-day weekend. When multiple options exist, the system processes chronologically.

Option 3 — If all weekends were worked, assign penalty pay to 2 weekend days and 1 adjacent weekday to create the 3-day weekend. The third weekend worked in the validation period always receives the penalty pay.

Rule 2a. — Consecutive Days Off with Weekend

Qualification

This rule validates whether an employee had 2 consecutive days off during each fortnight of the 4-week validation period and that at least one instance of consecutive days off in the 4-week window occurred on a weekend (Saturday+Sunday).

Penalty pay

When the employee does not meet the requirement, the extension processes the following steps:

Step 1 – Creates a weekend off in one of the fortnights.

The extension looks for a Saturday or Sunday off in any of the 2 fortnights and assigns penalty pay to the other worked weekend day.

When neither a Saturday nor a Sunday off is found, applies penalty pay to both worked weekend days.

In this situation, penalty pay always applies to the third weekend, which falls in the second fortnight.

Step 2 – Create 2 consecutive days off in the other fortnight.

The extension looks for 2 consecutive days off in the remaining fortnight; when found, no further action takes place.

When not found, the extension looks for 1 day off and applies penalty pay to the preceding worked day.

If the targeted penalty day falls outside the validation period, penalty pay applies to the following worked day.

When no days off are found, penalty pay applies to the first 2 worked days found in the fortnight.

Rule 2b. — Consecutive Days Off without Weekend

Qualification

This rule applies to employees with a signed MVA who waived their right that the 2 consecutive days off for each fortnight must include the weekend at least once.

Rules 2a and 2b are mutually exclusive and cannot be combined in the same rule set.

Penalty pay

This variant only validates that 2 consecutive days off are found in each of the fortnights. Only 1 step is applicable:

The extension looks for 2 consecutive days off in each of the fortnights; when these are found no further action is taken.

When not found, the extension looks for 1 day off and penalty pay applies to the preceding worked day.

If the targeted penalty day falls outside of the validation period, penalty pay applies to the following worked day.

When no days off are found, penalty pay applies to the first 2 worked days found in the fortnight.

Rule 3 — Consecutive Days Off 2+2 or 3

Qualification

This rule validates whether an employee had 2 consecutive days off in each fortnight of the 4-week validation period or had 3 consecutive days off that spanned the 2 fortnights.

Penalty pay

The extension applies the following options, cascading from the least expensive option 1 (single day penalty) to the most expensive option 3 (multiple days penalty.)

Option 1 — Finds any 2 consecutive days off in the fortnight and applies penalty pay to the preceding worked day, thereby creating a 3-day off period.

If the targeted penalty day falls outside the validation period, penalty pay applies to the following worked day.

Option 2 — Finds any 1 day off in the fortnight, and applies penalty pay to the preceding worked days, thereby creating a 3-day off period.

If the targeted penalty day falls outside the validation period, applies penalty pay to the 2 following worked days.

Option 3 — When no day off is found in the fortnight, always applies penalty pay to the first 3 worked days, thereby creating a 3-day off period.

Rule 4a. — Maximum Working Days in a Fortnight

Qualification

This rule validates that employees do not work more than a maximum number of days in a fortnight. The default threshold is 10 days, but is configurable.

Penalty pay

The system identifies the day when the maximum is reached, and penalty pay applies to all subsequent worked days.

Rule 4b. — Maximum Working Days in a 4-week Period

Qualification

This rule validates that employees do not work more than a maximum number of days in a 4-week period. The default threshold is 19 days, but is configurable.

Penalty pay

The system identifies the day when the maximum is reached, and penalty pay applies to all subsequent worked days.

Note: Worked shifts do not need to be consecutive for Rules 4a and 4b.

Although employees receive penalty pay when GRIA rules are violated, the best practice is to combine this extension with schedule rules to prevent creating a schedule that does not conform to regulations and results in penalty pay. The following schedule rules are instrumental in avoiding penalty pay:

Schedule Rules
GRIA Rule Schedule Rule option
1. Regular Sunday Workers Schedule Event Rule = Minimum one 3 day weekend off every 4 weeks
2. Consecutive days off with or without weekend Schedule Event Rule = Minimum one Sat+Sun weekend off every 4 weeks
3. Consecutive days off 2+2 or 3
Amount Parameters
Parameter Format Amount
Minimum Consecutive Days Off per Week or # 2
Minimum Consecutive Days Off per 2 Weeks # 3
Minimum Days Off per 2 Weeks # 3
4. Maximum Working Days for Fortnight or 4-Weeks
Amount Parameters
Parameter Format Amount
Scheduled Days # 10
Weeks in Period # 2

Use case Rule 1 — Regular Sunday Workers

This GRIA rule is enabled in the employee's Schedule Rule Set.

The employee qualifies as a regular Sunday worker and has worked in the 4-week validation period as shown in the work calendar table.

Work calendar
Week Number Monday Tuesday Wednesday Thursday Friday Saturday Sunday
1         W VS  
2 W   W W W W W
3 W W     W W  
4 W W W       W
5 W W    

VE,

X

    

  • W = Worked

  • X = Extension run day

  • VS = Validation period start

  • VE = Validation period end

When the extension runs, it finds a full weekend off during week number 1. It creates the 3-day weekend equivalent by assigning penalty pay on the preceding Friday.

The penalty pay equivalent work rule AU-RET30-GRIA-PenaltyPay replaces the employee's active work rule, AU-RET30. This appears as a transfer in the employee's timecard, accompanied by a comment and note describing the date, time, validation period, original work rule, override work rule and rule violation.

Use case Rule 2a — Consecutive Days Off Rule with Weekend

This GRIA rule is enabled in the employee's Schedule Rule Set.

The employee has worked in the 4-week validation period as shown in the work calendar table.

Work calendar
Week Number Monday Tuesday Wednesday Thursday Friday Saturday Sunday
1

VS,
W

 W W W W W W
2 W W W   W W W
3 W W W W W W W
4 W W W W W  

VE,
W
5 X      

 

    

  • W = Worked

  • X = Extension run day

  • VS = Validation period start

  • VE = Validation period end

During week 4, the extension finds one weekend with at least one day off. It creates the 2 consecutive days off in that weekend by applying penalty pay on the Sunday during week 4.

In the other fortnight, 1 day off is found on Thursday during week 2, and the extension applies penalty pay to the preceding Wednesday.

The penalty pay equivalent work rule AU-RET30-GRIA-PenaltyPay replaces the employee's active work rule, AU-RET30, in each case. Both appear as transfers in the employee's timecard, accompanied by a comment and note describing the date, time, validation period, original work rule, override work rule and rule violation.

Use case Rule 2b — Consecutive Days Off Rule without Weekend

This GRIA rule is enabled in the employee's Schedule Rule Set.

Work calendar
Week Number Monday Tuesday Wednesday Thursday Friday Saturday Sunday
1

W

 VS,
W		 W W W W W
2 W W W   W W W
3 W W W W W W W
4 W W   W W  

W
5 VE,
X		      

 

    

  • W = Worked

  • X = Extension run day

  • VS = Validation period start

  • VE = Validation period end

The extension looks for 2 consecutive days off in each of the fortnights.

In the first fortnight, 1 day off is found on Thursday during week 2.

In the second fortnight, days off are found on Wednesday and Saturday during week 4.

Because there is no obligation for a weekend to be included, the extension creates consecutive days off on Wednesday during week 2 of the first fortnight and Tuesday during week 4 of the second fortnight.

The penalty pay equivalent work rule AU-RET30-GRIA-PenaltyPay replaces the employee's active work rule, AU-RET30, in each case. Both appear as transfers in the employee's timecard, accompanied by a comment and note describing the date, time, validation period, original work rule, override work rule and rule violation.

Use case Rule 3 — Consecutive Days Off 2+2 or 3

This GRIA rule is enabled in the employee's Schedule Rule Set.

The employee has worked in the 4-week validation period as shown in the work calendar table.

Work calendar
Week Number Monday Tuesday Wednesday Thursday Friday Saturday Sunday
1

W

 VS,
W		 W W W W W
2 W W W W W   W
3 W W W W W W W
4 W     W W  

W
5 VE,
X		      

 

    

  • W = Worked

  • X = Extension run day

  • VS = Validation period start

  • VE = Validation period end

The extension finds only 1 day off on Saturday during week 2 of the first fortnight. It applies penalty pay to the 2 preceding days, Thursday and Friday.

In the second fortnight, the extension finds 2 consecutive days off on Tuesday and Wednesday during week 4. It applies penalty pay to the preceding Monday.

Each penalty pay appears as a transfer in the employee's timecard, accompanied by a comment and note describing the date, time, validation period, original work rule, override work rule and rule violation.

Use case Rule 4a — Maximum working days in a 2-week period

This GRIA rule is enabled in the employee's Schedule Rule Set.

The employee has worked in the 4-week validation period as shown in the work calendar table.

Work calendar
Week Number Monday Tuesday Wednesday Thursday Friday Saturday Sunday
1

 

 VS
          
2              
3 W W W W   W W
4   W W W W W

W
5 VE,
X		      

 

    

  • W = Worked

  • X = Extension run day

  • VS = Validation period start

  • VE = Validation period end

The extension identifies 12 working days in the fortnight, with Friday of week 4 as the tenth working day. The next 2 worked days, Saturday and Sunday of week 4, receive penalty pay. These days appear as a transfer in the employee's timecard, accompanied by a comment and note describing the date, time, validation period, original work rule, override work rule and rule violation.

Before you configure this integration, you must do the following:

  1. Configure Access to Integrations.
  2. Configure the following:
  • Comment: Configure a comment that the integration adds to the timecard with the penalty pay work rule transfer. The punches category must be selected during configuration. See the Comments topic.
  • Paycode: Configure hours-based paycodes that are used by the rule validation. See the Paycode definition topic.
  • Combined Paycode: Configure a combined paycode that tracks all hours-based paycodes used by the rule validation. See the Combined Paycodes topic.
  • Schedule Rule Sets: Configure schedule rule sets that are used by the process to determine the treatment for each GRIA working day and weekend rule. Assign the rule sets to employees who benefit from the GRIA Working Days and Weekends Compliance extension. See the Configure schedule rule sets topic.
  • Work Rules: Configure work rules that are used for penalty pay calculation. Each work rule assigned to GRIA workers that is subject to penalty pay must have an alternative version whose name contains the suffix defined in the Override Workrule Suffix integration parameter. See the Work Rules topic.

  1. Get the URL, User, and Password for the APIGatewayServer.

Version Description
1

Initial release.
This extension automatically applies penalty pay when an employee's actual hours violate specified scheduling rules.
1.1

Addressed an issue where performance did not meet expectations. Optimization changes include:

  • The addition of a Flow component shape that splits the higher volume of Hyperfind based on the defined batch size.

  • The batch size is now reduced to 100 when calling the Timecard API.

  • The code now retrieves worked shifts-related data from the Timecard API.
iPack_v2 The GRIA Working Days and Weekends Compliance integration delivery is now by way of an iPack.

Deploy the GRIA Working Days and Weekends Compliance integration

For more information, see the Deploy Integrations topic.

  1. Open the Integration Template Designer: Select Main Menu  > Administration > Application Setup > Integrations Setup > Design Integration Templates.

    Note: If prompted, enter your Username and Password. Click Tap Log in.

  2. Make sure that the Account is correct. If not, select the right account.

  3. Select the Deploy tab > Integration Packs.
  1. From the list in the left column, search for and select the Pro WFM GRIA Working Days and Weekends Compliance Extension integration.

  1. From Unattached Environments, select the environment in which to deploy the integration process for the selected integration. Click Tap the double-left arrows button Select items.

Configure the GRIA Working Days and Weekends Compliance integration settings

Select the environment

  1. Select the Manage tab > Atom Management.
  2. Select your environment.

Select environment extensions

  1. In Administration, click tap Environment Extensions.
  2. In Process Filter, click tap the magnifying glass Search button. It can take several seconds before the button becomes active.
  1. Scroll to and select the integration pack: GRIA Working Days and Weekends Compliance > GRIAWorkingDaysandWeekendsCompliance_iPack_v2.

Configure connection settings

Caution: If you select Use Default for the connection settings and process properties, ensure that Value is blank. If Value is not blank, that value overrides the default value whether or not Use Default is selected or cleared. Example: If the default value is abc, but Value shows xyz, the integration uses xyz regardless of the setting of Use Default.

  1. Select Connection Settings.

  2. From the Connection list, select and configure the following:

    Connection Settings
    Setting Required Actions
    GRIAWorkingDaysandWeekendsCompliance_iPack_v2_APIGatewayServer Required

    To change the default API gateway server:

    1. Clear Use Default.
    2. Enter the URL to the server.

      Example: <tenantURL>/api
    GRIAWorkingDaysandWeekendsCompliance_iPack_v2_RuleSet_CRT Required

    Enable Override.
    GRIAWorkingDaysandWeekendsCompliance_iPack_v2_Locale Required Enable Override.

Configure process properties

  1. Select Process Properties.

    Caution: Do not edit the default values of the AuthenticationProperties. By default, cookies are enabled and set the values for authentication properties.

  2. Select GRIAWorkingDaysAndWeekendsCompliance_iPack_v2_CRTConfig to set process properties that must be configured before the integration can run. This main process starts the integration process and handles errors.

Process Properties
Process property name Column header value
_GRIAWorkingDaysAndWeekendsCompliance_iPack_v2_RuleSet_CRT Schedule Rule Set,1. Regular Sunday Workers,2a. Consecutive Days Off with Weekend,2b. Consecutive Days Off without Weekend,3. Consecutive Days Off 2+2 or 3,4a. Maximum Working Days per Fortnight,4b. Maximum Working Days per 4 Weeks
_GRIAWorkingDaysAndWeekendsCompliance_iPack_v2_Locale_CRT Parameter Name,Locale Policy,Message,Description

Configure cross-reference tables

Cross-reference tables (CRT) are the look-up tables that the integrations use to translate parameter values. One or more data values from the source system can be used to assign one or more parameters in the destination system.

  • If more than one row matches a reference value, the first match is the output value.
  • If no match is found, the output value can be null, or the integration can produce errors.
  1. Select Cross Reference.
  2. From the Cross Reference dropdown list, select a GRIAWorkingDaysAndWeekendsCompliance table.
  3. Select Override, which allows you to:
  • Download the tables when you run the integration.
  • Edit the table cells in Extensions.
  1. When you finish, click tap OK.

Repeat the steps for each of the GRIAWorkingDaysAndWeekendsCompliance tables.

GRIAWorkingDaysAndWeekendsCompliance_iPack_v2_RuleSet_CRT: Identifies the treatment of each GRIA rule related to a schedule rule set.

When employees fall under the same GRIA rules, consider assigning the same Schedule Rule Set to each.

For employees who have signed an MVA, consider creating individual Schedule Rule Sets that align with their GRIA rule selections.

GRIA Working Days and Weekends Compliance — Rule Set CRT structure
Column name Description
Schedule Rule Set

The schedule rule set assigned to an employee.
1. Regular Sunday Workers

Determines whether rule 1 applies when Schedule Rule Set is assigned to an employee.

True — Rule 1 applies.

False — Rule 1 does not apply.
2a. Consecutive Days Off with Weekend

Determines whether rule 2a applies when Schedule Rule Set is assigned to an employee.

True — Rule 2a applies.

False — Rule 2a does not apply.
2b. Consecutive Days Off without Weekend

Determines whether rule 2b applies when Schedule Rule Set is assigned to an employee.

True — Rule 2b applies.

False — Rule 2b does not apply.
3. Consecutive Days Off 2+2 or 3

Determines whether rule 3 applies when Schedule Rule Set is assigned to an employee.

True — Rule 3 applies.

False — Rule 3 does not apply.
4a. Maximum Working Days per Fortnight

Determines whether rule 3 applies when Schedule Rule Set is assigned to an employee.

True — Rule 4a applies.

False — Rule 4a does not apply.
4b. Maximum Working Days per 4 Weeks

Determines whether rule 3 applies when Schedule Rule Set is assigned to an employee.

True — Rule 4b applies.

False — Rule 4b does not apply.
Note:

  • The Schedule Rule Set value is case-sensitive and must match the configured value in the system.

  • True and false values in the GRIAWorkingDaysAndWeekendsCompliance_iPack_v2_RuleSet_CRT are not case-sensitive.

  • Blank rule columns are considered false.

  • Rules 2a and 2b are mutually exclusive and cannot be combined. You can activate either 2a or 2b.

  • Rules 4a and 4b are mutually exclusive and cannot be combined. You can activate either 4a or 4b.

GRIAWorkingDaysAndWeekendsCompliance_iPack_v2_Locale_CRT: Allows translation of messages and labels into different languages.

GRIA Working Days and Weekends Compliance — Locale CRT structure
Column header Description
Parameter Name Key for which localization is defined.
Locale Policy Locale Policy.

You can use an asterisk (*) as a wildcard, but put the less-restrictive locale policy names at the bottom of the table because the integration scans cross-reference tables from the top.
Message Message shown in Additional Details, or value of the label defined in the Run Summary section.

Example: Comment was not provided.
Description The description that is shown in Additional Details.

Example: The employee is not assigned a shift.
Note:

  • Localization of integration extensions remains optional, but is supported.

  • The cross-reference table (CRT) holds all messages represented with standard English labels; these apply to all locales when the Locale is set to a wildcard (*).

  • Some or all messages can be translated by adding lines to the table in their preferred translation for specific locales. Messages for the most commonly used Locale Policy should be defined at the top of the CRT.

  • Names of the parameters in the CRT column "Parameter Name" must be used as is. If any parameter value needs to be localized for a different Locale Policy, copy the "Parameter Name" with the * Locale Policy, add a new row to the CRT with the appropriate Locale Policy, and then add the localized values in the Message (or Value) and Description CRT columns.

  • Do not enter values in the CRT column "Description" if it is blank.

  • Do not modify placeholders (<>) or the configurable values that are included in the CRT column "Message" (or "Value").

Sample Locale CRT content

Parameter name

Locale policy

Message

Description

Error_MessageBlankComment

*

Comment is not configured.

 

Error_MessageBlankHyperfindorEmployeeIDs

*

Employee IDs cannot be found in UKG Pro WFM.

 

Error_MessageBlankMinimumWorkedHours

*

Minimum Worked Hours (hh:mm) is not configured.

 

Error_MessageBlankOverrideWorkruleSuffix

*

Override Workrule Suffix is not configured.

 

Error_MessageBlankScheduleRuleSet

*

Schedule Rule Set is not configured.

 

Error_MessageBlankScheduleRuleSetDesc

*

Schedule Rule Set '<Rule Set>' does not exist in UKG Pro WFM

 

Error_MessageDetailsLog

*

All employees are invalid. Please refer to Additional Details for further information.

 

Error_MessageFutureDateValidation

*

Anchor Date must be less than or equal to the integration run date.

 

Error_MessageInvalidAnchorDate

*

End Date format is invalid.

 

Error_MessageInvalidComment

*

Comment '<Comment>' does not exist in UKG Pro WFM.

 

Error_MessageInvalidCommentCategory

*

Comment '<Comment>' must be configured with the Punches category.

 

Error_MessageInvalidCommentNoteLength

*

Comment Note cannot exceed 250 characters.

 

Error_MessageInvalidEmployeeIds

*

Invalid Employees.

Employee with ID '<Person Number>' does not exist.

Error_MessageInvalidEmployeeIdsDesc

*

Employee ID '<Person Number>' does not exist in UKG Pro WFM

 

Error_MessageInvalidMaximumWorkingDaysper4Weeks

*

Maximum Working Days per four weeks must not be greater than 28.

 

Error_MessageInvalidMaximumWorkingDaysperFortnight

*

Maximum Working Days per fortnight must not be greater than 14.

 

Error_MessageInvalidMinimumWorkedHours

*

Minimum Worked Hours (hh:mm) must be configured using hh:mm format.

 

Error_MessageInvalidRuleSet

*

Invalid Schedule Rule Set.

Schedule Rule Set defined in the CRT is invalid.

Error_MessagePersonNumber

*

Person Number

 

Error_Messageworkruledescription

*

Override Workrule does not exist in UKG Pro WFM.

 

Message_BlankWorkedHours

*

Worked Hours (Combined paycode) is not configured.

 

Message_CommentNote

*

Validation Period: <ValidationPeriod> || Override Work Rule: <OverrideWorkrule> || Work Rule: <Workrule>|| Violation Type: <ViolationType>

 

Message_EmployeeNotSignedOff

*

Validation Period falls in signed-off period.

 

Message_EmployeeNotSignedOffDesc

*

Validation Period <Validation Period> falls in signed-off period for employee <Employee ID>. Last sign-off date <sign-off date>.

 

Message_InvalidRuleSetDesc

*

Schedule Rule Set <Schedule Rule Set> in CRT is not correct.

 

Message_InvalidWorkedHours

*

Worked Hours (Combined Paycode) <Worked Hours> does not exist in UKG Pro WFM.

 

Message_InvalidWorkedHoursPaycodeType

*

Worked Hours (Combined Paycode) <Worked Hours>  is not a combined paycode.

 

Message_NotASundayWorker

*

Not a Sunday Worker.

Employee <Employee ID> is not a Regular Sunday Worker.

Message_NullRuleSet

*

Schedule Rule Set assigned to the employee is not configured in the CRT.

Schedule Rule set <Schedule Rule Set> is not configured in the CRT.

Message_RuleSetIsNotAssigned

*

Rule Set not assigned.

Schedule Rule Set not assigned to an employee .

Message_TransferStringRemoved

*

Transfer string removed for <PunchDateTime>.

 
Note:

  • All error and additional details messages display in the locales of the user executing the integration.

  • All notes added to the employee's timecard display in the employee's locale.

Custom tags used in the comment notes are replaced with actual values as described in the custom tags table.

Custom tags
Tag Description
<ValidationPeriod> The date range of the 2- or 4-week validation period.
<OverrideWorkrule> The transfer work rule used to calculate the penalty pay.
<Workrule> The employee's original work rule.
<ViolationType> Name of the violated rule, such as 1. Regular Sunday Workers.
|| The character which indicates that subsequent content appears in a new comment.

After the integrations are deployed and the connection settings and process properties are configured, install the integrations to make them available for running or scheduling.

Note:
  • An integration template is the configured integration that you deploy to an Atom and then install to make available for running or scheduling.
  • An installed integration is a single instance of an integration that is based on an integration template. When you install an integration, you can define parameters or set parameters to be defined when the integration is run.
  1. Select Main Menu  > Administration > Application Setup > Integrations Setup > Install Integrations.
  2. Click Tap Create .
  3. In Integration Name, enter a unique name, such as GRIAWorkingDaysAndWeekendsCompliance_iPack_v2.
  4. (Optional) Enter a Description.

Note: Do not select API Integration.

  1. In File Access, select None to not select a connection.
  2. If the person who runs the integration does not have full access to integrations, select Execute Integration with System Account. This allows the integration access to all APIs in the FAP, and the relevant permissions and data, regardless of the FAP and GDAP of the person who runs the integration.

  3. (Optional) Select Re-Run to allow repeated runs of the integration with the same parameter values as the previous run.

  4. Email Notifications

    (Optional)

    1. Select Yes to send email and control center notifications for integration runs.
    2. Enter the email addresses of the recipients for the following types of run status. For multiple recipients, separate the addresses by a comma, but no spaces:

      In Progress — The integration run started and has not finished.

      Completed — The integration ran successfully without errors.

      Failed — The integration ran successfully, but one or more records have errors. The integration run is treated as failed. If Abort on Failure is configured in an integration set, the integration set stops.

      Completed with Errors — The integration run has errors or could not run.

  5. In Skip Configuration, select None (default) to allow multiple integrations to run at the same time or with the same data without restrictions.

Note: Do not select Allow Minute Interval.

  1. Integration template and parameters
    1. In Integration Template, select GRIAWorkingDaysAndWeekendsCompliance_iPack_v2.
    2. Click Tap Assign .
    3. In Integration Parameters, you can override default settings. Click Tap Create .

    4. Complete the configuration for each integration control parameter value.

    5. Click Tap Save.

      Repeat this step for each integration control parameter that supports the GRIA Working Days and Weekends Compliance process.

      Integration Parameters
      Parameter name Description / User prompt / Mandatory Template parameter Parameter type
      Hyperfind or Location

      The default Hyperfind or Location query that contains the employees for whom the integration is run.

      Default = 1 (All Home)

      User prompt = Yes

      Note: Ad-hoc Hyperfinds are not supported.

      All Home does not include terminated and inactive employees even if they have totals during the period. To include these totals, configure a Hyperfind that includes terminated and inactive employees, and select that Hyperfind in this process property.

      The maximum number of employees in a Hyperfind is 3500. To process more employees, divide the population into smaller Hyperfinds to run sequentially.

      		 HyperfindorLocation Hyperfind
      Employee IDs

      A comma-separated list of specific employees for whom the integration is run.

      When no value is entered, the integration defaults to the HyperfindOrLocations parameter.

      To process the integration for only a limited group of employees, enter the person numbers as defined in the source system, each separated by a comma (,) but not spaces.

      User prompt = Yes

      		 EmployeeIDs Text
      Anchor Date

      Date used to calculate the validation period.

      Supported values include: Effective day or Effective day+1

      Default value = Integration run date

      User prompt = Yes

      Note: If not provided, the integration uses the integration run date as the Anchor Date.

      		 AnchorDate Date
      Comment

      Comment added by the integration to the work rule transfer in the timecard.

      User prompt = No

      		 Comment Text
      Worked Hours (Combined Paycode

      Combined pay code used to total the employee's primary hourly paycodes.

      User prompt = No

      		 WorkedHours(CombinedPaycode) Text
      Minimum Worked Hours (hh:mm)

      The minimum number of hours charged to a paycode before the day qualifies as a work day.

      User prompt = No

      		 MinimumWorkedHours(hh:mm) Text
      Override Workrule Suffix

      The suffix added to the primary work rule name that identifies the appropriate work rule transfer to calculate penalty pay.

      User prompt = No

      Note: Each work rule assigned to GRIA workers that is subject to penalty pay, must have an alternative version containing this suffix in the configured name.

      		 OverrideWorkruleSuffix Text
      Enable Edits

      Determines whether paycode edits are made in the timecard when the bonus payout date falls in a signed-off period.

      Default value = true

      User prompt = No

      Note: If left blank, the integration assumes a value of false.

      		 EnabledEdits Boolean
      Threshold for 4a.Maximum Working Days per Fortnight

      The maximum number of days in a 2-week period that an employee works before qualifying for penalty pay.

      Default value = 10

      User prompt = No

      Note: This value must not exceed 14.

      		 Thresholdfor4a.MaximumWorkingDaysperFortnight Number
      Threshold for 4b.Maximum Working Days per 4 Weeks

      The maximum number of days in a 4-week period that an employee works before qualifying for penalty pay.

      Default = 19

      User prompt = No

      Note: This value must not exceed 28.

      		 Thresholdfor4b.MaximumWorkingDaysper4Weeks Number

  1. Ensure that the generic data access profiles (GDAP) allow access by the people who need to run the installed integrations. See Configure Access to Integrations.

Run integrations to test that the configuration is set up correctly.

Run the integration

  1. Select the integration:
    1. Select Main Menu  > Maintenance > Integrations. 
    2. Click Tap Run an Integration . 
    3. Select the GRIAWorkingDaysAndWeekendsCompliance_iPack_v2 integration from the list. Click Tap Select. 
    4. (Optional) Enter a unique Integration Run Name to make it easier to identify the run of the integration. Otherwise, the system assigns a default name, which ends with a date and time stamp.
  2. Set parameter as follows:
    • Hyperfind or Location: Select a Hyperfind or location query of employees.
    • Employee IDs: To process data for only a limited group of employees, enter the person numbers, as defined in the source system, each separated by a comma (,) but no spaces.

      For 3 employees: 13997,15556,20012

    • Anchor Date: Enter the date to identify the validation period.

  3. Select the following:

    • Run Integration: If this is the first time this integration is being run.
    • Re-Run: If this integration has been run before, and the status is not In-Progress, you can run the integration again without entering the parameter values again. Click Tap Yes to continue, or No to not run the integration and to return to the parameter settings.

  4. Wait for the confirmation that the integration completed or failed. Close the panel.
  5. Click Tap Refresh . 
  6. To see details, select the integration run. Select Run Summary.

Check the results

Status indicators

  •  In-Progress: The run of this integration has not yet completed.
  •  Completed: The integration ran successfully without errors.
  •  Scheduled: This integration is scheduled to run later or repeatedly.
  • (Grayed out) Scheduled but Deleted: This integration is scheduled to run, but the integration template has been deleted. When it runs, it will generate an error. To prevent this error, delete the scheduled integration run.
  •  Completed with Errors: The integration ran successfully, but one or more records have errors. The integration run is treated as failed. If Abort on Failure is configured in an integration set, the integration set stops.
  •  Failed: The integration run has errors or could not run.
  • To troubleshoot and resolve errors, do the following:

    Check the Run Summary for details.

    • To troubleshoot all types of errors, or if the Run Summary shows a large number of errors, click tap Go to Additional Details (if available), or click tap the Source File to open and examine the input source file.
    • (Only for import integrations) To troubleshoot and resubmit integrations that have transactional or data errors, click tap Go to Transaction Assistant.

To check the results in more detail:

  1. Click Tap the tile for the integration run.
  2. Click Tap Run Summary to see the results of the integration run.

    Example Run Summary details

    Note: The available details vary by integration and configuration.

    • Integration Run Name: Name of this run of the integration.
    • Process Name: Name of any integration set that includes this integration.
    • Integration Name: Name of the installed integration.
    • Integration Reference ID: Unique identifier for this integration run (to help in troubleshooting errors).
    • User: The person or user account that ran the integration.
    • Integration Type: Import, Export, or None
    • Start Date: Date and time when the integration run started.
    • End Date: Date and time when the integration run finished.
    • Status: In-Progress, Completed, Completed with Errors, or Failed.
    • Records Processed: Number of records that were processed.
    • Records Created: Number of records that were created.
    • Errors: Number of records that failed.
    • Source Files, Output File, and Error Files: For file-based import integrations, use Manage SFTP to access the source and output files on the inbound (source) and outbound (destination) SFTP folders. See the Manage SFTP topic.
  3. Log in to the destination system and ensure that the data has been correctly updated.

Note: You can schedule integrations and integration sets to run once later or at a recurring frequency. See the topic.

API Details

API Name

Type

Resource Path

Description
Retrieve Persons POST /v1/commons/persons/extensions/multi_read Returns multiple person records based on search criteria. Search criteria includes personid, personnumber, jobassignmentid, username, useraccountid, and badgenumber.
Retrieve Comments-Manager GET /v1/commons/comments Returns a filtered list of comments.
Retrieve User Preferences for Current User GET /v1/commons/user_preferences/locale_policy?userCurrent=true Returns user preferences for the current user or tenant.
Retrieve User Preferences for Tenant GET /v1/commons/user_preferences/locale_ policy?tenantDefault=true Returns user preferences for the current user or tenant.
Execute Hyperfind Query POST /v1/commons/hyperfind/execute Retrieves employee details using Hyperfind id or location id.
Retrieve Rule Set Assignments for Multiple Employees POST /v1/commons/persons/schedule_rule_sets/multi_read Returns a list of rule set assignments for multiple employees, a date, and a context.
Retrieve Pay Codes GET /v2/timekeeping/setup/pay_codes Returns one or more paycodes available to the logged-in manager by object references.
Retrieve Timecards as Employee POST /v1/timekeeping/employee_timecard/multi_read Returns an employee timecard. Required parameters include employee ID or person number along with a date range or symbolic period ID.
Retrieve Timecard Data for Multiple Employees POST /v1/timekeeping/timecard_metrics/multi_read Returns timecard data for a set of employees or locations.
Bulk Enable Edits POST /v1/timekeeping/enable_edits/import Enable edits in a signed-off region for employees in bulk. Enable Edits is available when an employee has permission to edit signed-off timecards when the timecard is not in an editable state.

Update Timecard as Manager

POST

/v1/timekeeping/timecard

Updates a timecard for an employee as a manager. Add, update, or delete punches, paycode edits, hours worked, and exception Comments.
Retrieve Timecards as Manager POST /v1/timekeeping/timecard/multi_read Returns a list of timecards based on the employees or Hyperfind details provided. Required parameters include employee ID or person number along with a date range or symbolic period ID.