Understanding the Upcoming Policies Engine Upgrade

Arcoro is pleased to announce the completion of the policies engine upgrade. The policies engine takes a time record and applies specific rules to it so that regular and overtime hours are calculated correctly. Some of these rules include autolunch deductions, overtime rules, and rounding. The new policy engine provides increased performance and the ability to add new policy offerings.

While most customers will not experience any difference after being upgraded to the new policies engine, Arcoro has identified a handful of scenarios that have been updated with the newest version. These scenarios are outlined below to help you better prepare for the upgrade.

Please contact support with any questions with the request support link at the top of the page.

Scenarios

Concurrent Policies Set at the Shift, Location, and Employee level

In the current version, a policy, such as daily overtime, can be set for a shift, location, or group of employees. If a time record qualified for a daily overtime policy adjustment it could then be changed by that policy three times, set at the shift, location, and employee levels. The policies engine would apply daily overtime first at the shift level, then at the location level, and finally at the employee level, essentially applying policies to a time record 3 different times.

With the policies engine upgrade, Arcoro moved to a precedence model, where we only apply policies to a time record once, based on a predefined priority. The priority of applying policies to a time record is now: (1) shift, (2) location, (3) employee. Taking the same example above, where a time record qualifies for daily overtime at the shift, location, and employee level, we would only apply the shift overtime, since it was first in the set order to meet the overtime criteria.

Autolunch Ordering when there is a Daily Overtime Policy

In the current policies engine, time records are ordered by type of time record first (e.g., Standard Time or Autolunch records), then order date, then overtime is applied from top to bottom.

In the scenario below, the autolunch record falls after the 1:00 PM start time record, even though the autolunch starts at 12:00 PM.

image1.png

In the newest version of the policies engine, the policy engine ignores the type of time record. It orders all the time records by order date, then applies the overtime from top to bottom. The final total hours will be the same, just displayed slightly differently. The change was made to better reflect when the auto lunch happens during the workday. See the example below.

image2.png

Autolunch Assignment for Records with Identical Timespans

When there are two time records with identical timespans, the autolunch policy deducts from whichever record came first when sorting by timespan.

In the example below, the autolunch location/cost code is associated with the location "Tucker High School" and cost code "In", even though the corresponding time record is not the earliest in the day.

image3.png

After the upgrade, we have updated the sorting to sort by timespan and order date, which means the autolunch will deduct from the earliest record of the day if there are records with identical time spans.

image4.png

Travel Policy Location Assignment – Departure Location

Before the upgrade, the policies engine was assigning the incorrect location for a travel time record if there were two consecutive time records that both had a stop time that met the minimum threshold to have a travel policy applied.

In the example below, the location for the highlighted travel time record should be TEST – NUMERO UNO 110 because that is the location of the preceding time record where the stop time meets the threshold to have the travel policy applied.

image5.png

In the upgraded version of the policies engine, this has been corrected so that the travel policy assigns the location of the travel record from the location of the preceding record that met the threshold, not the earliest. In the example below, Location A is assigned the travel record, not L001-Location 1.

image6.png

Autolunch Ignoring Excluded Cost Codes

Before the upgrade, autolunch deductions could be taken out of an excluded cost code if it happened to fall as the last record of the day. In the example below, "Sick" is an excluded cost code and the autolunch record is deducting time from the "Sick" cost code.

image7.png

After the upgrade, the autolunch policy will ignore any excluded cost codes when deducting time.

image8.png

Autolunch as Only Record on a Day

Before the upgrade, certain data conditions deducted an autolunch from the overtime bucket even when the overtime balance was zero, resulting in a negative overtime balance. This was observed when a time record spanned midnight, and the autolunch record was the only record for the following day.

image9.png

After the upgrade, since the record is created on a new day and is the only record for that day, the Auto Lunch will always deduct from Regular as the Daily OT has zero hours for that day.

image10.png

Legacy Time Summit Enterprise Autolunch Setting

*This scenario only applies to legacy Time Summit Enterprise customers who use the Autolunch setting and never updated when migrating to Connect.

There is an autolunch setting in Time Summit Enterprise which states that if a time record overlaps the specified autolunch start time, the Location and Cost Code of that time record will also be assigned to the autolunch. This setting was not carried over when autolunch was built in ExakTime Connect.

image11.png

With the upgrade, this setting will be ignored, so if a time record overlaps the specified autolunch start time, the Location and Cost Code assigned to the autolunch record will pull from the time record with the longest time span.

image12.png

FAQs

When will my site be enabled with the Policy Engine Upgrade?
The policies engine upgrade is being phased out to customers slowly over the second and third quarters of 2022. As the upgrade is turned on for ExakTime portals, all customers will receive an email notifying them that the upgrade is coming. Users will also see a notification message in the ExakTime application near the same time. You can expect that the upgrade will be enabled within a month of these notifications being sent.
Is there anything I need to do to prepare myself or my team for the change?
No, the change will take place without any additional work or configuration. Enablement is handled by the ExakTime team.
What do I do if I see an issue?
Please contact product support and the representative can log an issue with the appropriate team. If you are unsure of how to log a ticket with our support team, please refer to the following article.
Can I opt out of the Policies Engine enablement?
No, this will not be possible. The move to the new Policies Engine is a prerequisite for future enhancements to the ExakTime application. As such, we want to ensure all customers are using the upgraded engine.
Is the Policies Engine Upgrade the same project as Time Reconciliation Upgrade?
No, these are separate projects. Both affect ExakTime time record processing and occur outside of the visible user experience on the backend of the application. The projects will have separate timelines and be communicated separately.
Was this article helpful?
1 out of 1 found this helpful