Introduction
There are several different industries such as retail. manufacturing. real estate, construction etc. where there are premiums applicable on work performed and overtime payable on extension of work hours outside of the planned work schedule timings.
These requirements usually meander around the standard SuccessFactors Time Tracking solution and hence require the build of configuration logic to achieve the right combination of time type groups and time valuation rules.
Sometimes. a lot of these requirements are quite common in the various markets where the payment of overtime/shift premiums/payroll linked payments etc. take high priority while evaluating an employee's worked hours.
In this blog, I will walk through a similar scenario that was recently encountered for a group of employees who needed to paid a differential OT rate based on certain conditions. This is a very common scenario and I have implemented this multiple times in the erstwhile SAP Time Management (on premise) positive time product. This time around, while implementing it in SF time tracking, I can now vouch for the flexibility and functional robustness provided by this product from SAP launched in January 2021. It is at par in many ways to the traditional SAP on-premise time management product.
Scenario Description
An APAC region client has a scenario wherein the overtime hours worked by their employees are paid at different rates based on the day of the week. Specifically, they need the system to identify if the work done is on a Saturday and/or Sunday and accordingly the OT rates are to be applied in the system to those hours worked. We need to note that the condition here is to be able to decipher the days as being Saturday and Sunday instead of non - working day! So for e.g. if my employee was in fact scheduled to work on a Saturday/Sunday and the hours were booked as per the planned time then no OT is applicable but in case it was outside the planned time, the specific OT rates applicable for SAT/SUN are to be applied. If there are no hours scheduled on Saturday and/or Sunday (ideal scenario) then all the hours need to be accounted as overtime and the correct rates to be applied.
I have also come across scenarios wherein, out of the hours worked on Saturday and/or Sunday, there could be bands during which a particular shift premium also would be included in addition to overtime itself. Some clients also implement the payout of meal allowances that need to be generated in the system for certain shift work on a Saturday / Sunday.
For this blog, I have considered the scenario for payment of OT rates of 250% of daily rate if the employee comes to work on a Sunday. For the purposes of this blog, I have assumed a fixed pattern that has no working hours on Sunday. The rules can be extended/built to consider only the differential hours between planned and recorded working times in case the client does have shift patterns with planned time on Sunday. I have also considered that the shift premium of 175% for any hours worked post 8 PM.
A logical flow diagram for this scenario would be like this:
Configuration Features Used For This Scenario
Before we begin discussing the configuration steps, we need to understand some of the basics of time tracking and how they tie in with the whole solution.
A] Time Records Filter
The major premise of the scenario described above is the identification of the day of the week - is it a Saturday or a Sunday and to use this information to apply the different OT rate accordingly. How would we distinguish the Saturday/Sunday from a normal working day? Here, we will make use of the SuccessFactors Time Tracking feature of Time Records Filter. The time records filter does exactly what its name suggests - it filters the time records to identify whether it is a Saturday or a Sunday. The configuration steps will be described later in this blog.
B] Time Type Groups
Time type groups are basically used in time valuations to either hold the intermediate calculated values from the time valuations or as an outcome of the time valuation for payout to payroll. In short, they are used as variables in a program code that can hold values and continue to process them in further time valuation rules or be part of a counting events etc.
C] Time Valuations
How do you identify and process the input time data such that the employees that record their time inputs through clocks/allowance types etc. are paid correctly? The feature of time valuation takes care of this aspect. Basically, time valuation is like an evaluation of the employee input time data and generates outputs in terms of either time payouts, OT, shift premiums etc. based on the conditions built into the time valuation rules. For the purpose of our scenario and by extension, for shift and OT differential rates & premium payouts purposes, the following main types of valuations, applicable to this scenario, will be useful to know.
C.1] Aggregate Input Group and Split
This valuation type is used when you want to valuate clock times taking into account only the duration of this clock data. For e.g. my employee has clocked in at 9 AM and has clocked out at 6 PM so this valuation type will evaluate the duration between the clock in - clock out recorded by the employee. This valuation type "aggregates" the various input time type groups, applies a threshold value [either a fixed value such as 8 hours or a time type group that contains a threshold value from planned time for example) and then "splits" the records into two main categories.
C1.1] Time type group above & below
Time type groups not fulfilling even one of the criteria will be put into time type group above while those that qualify to the criteria fall into time type group below. For e.g. in case I am checking if the total time worked by an employee is 8 hours then all the input groups falling within this range are put into time type group above while anything within this threshold goes into time type group below. Consider the following example:
C.2] Filter Input Groups & C.3] Filter segments from Input Groups
Filter input groups and filter segments from input groups are both similar, in that they filter the particular day/ segment of work in a day from the input groups and segregate them into time type group below (meets condition) and time type group above (doesn't meet condition). The below example will make it clear.
Configuration Flow for this scenario of OT on Sunday and Shift Premium Differential Rates
This "recorded working time" time type group will include all the inputs that are possible to be recorded by the employee in that particular day as below:
Client Scenario: Check for Overtime Pre-Approval to isolate only approved overtime which matches with recorded overtime clock hours
In such cases as point (1) and (2), a attendance time type called overtime is created in the system. Please note that this is a attendance time type as below:
This time type is then added into the "recorded working time" time type group as below:
Once this time type is added into the time type group, it will be part of the accumulation logic for the daily recorded working time classification.
The client can then allow their employee to record the overtime attendance on a particular day [in advance] into this time type and the record can be sent for approval to the manager. Once approved it gets captured into the system for further processing against the clock time recorded on that day. If there are more hours recorded than what has been approved, they will be disregarded and only the hours that the employee works in concurrence with the approved hours are sent for payroll processing. In case the employee works less hours than the approved overtime hours, the lesser of the two is sent for payroll processing. Refer to the table below for clarity on the OT approved for payroll processing.
Now that we have a holistic understanding of how recorded working times are calculated in the system and how it identifies various segments, let us see how we can now isolate various conditions such as public holiday work and non - public holiday (but Sunday) work.
A] For this purpose, we will first identify the working times that belong to a public holiday and the working times that do not belong to a public holiday.
In order to do so, we will use a time type group above that collects all the worked hours of an employee that do not fall on a public holiday so as to isolate them for further conditional checks such as working hours on Sunday.
B] In order to filter out the public holiday hours, we will use the time records filter feature in the time valuation rule as below:
The time records filter can be used for a variety of conditions such as PH & non - PH checks or day of the week checks. For the check on PH work hours, the below time records filter will suffice.
C] The non - PH work hours have been successfully segregated from the non - PH work hours using the above valuation rule. Moving ahead, we will now use the input time type group as the non PH work hours isolated above [Time Type Group NPH_INP] as the reference to isolate the work hours on Sunday.
This will be achieved by first creating a time records filter that checks if the day being evaluated is a Sunday and if yes, it will be segregated into a different time type group below as shown here. Since the requirement is to pay the overtime of an employee for Sunday at 250% - we will name the time type group accordingly.
C.1] Segregate Sunday hours from the Non PH hours from step B
Note that we are using the time valuation rule type as Filter Input Groups - this means that we are filtering the Sunday work hour records from the overall non - PH work hours collected in the previous time valuation rule. The time records filter is again used here so as to filter the day of the week and isolate the Sunday working hours only. These are to be paid at a rate of 250% of the daily rate and would serve to hold the hours to be sent to payroll for further payment processing.
Since we would like the hours (OT @ 250%) be paid through payroll - we will mark this as a time pay type as below:
D] Filtering time segments in a day to ascertain shift premium differential rates
Coming to the requirement on the payment of late night shift premium at 175% to employees who work from 8 PM to mid night, we will use the concept of the time valuation rule type - "Filter Segments from Input Time Groups"
Essentially what this entails is as below:
In this case, there will be no distinction on the day when the OT is worked in late night shift. (See below scenario for further segregation based on the day of the week = Sunday)
In this case too, as above with the OT hours, we categorize the time type group "Late Night Premium Pay" as time pay type for payout in payroll processing as below:
In case your business scenario is to pay the late night shift premium only for Sunday hours (OT worked on Sunday) then instead of using the input time type group WORK_REC, you can use the input time type group as Sunday OT@2.5% which we created in the time valuation rule for Sunday work hours and then use the time segment filter for the hours from 8 PM to 11:59 PM to further ascertain how many hours to be paid at 175% premium rate over and above the 250% OT rate.
Conclusion
SuccessFactors Time Tracking has introduced many different features and enhanced the product to cater to various complex and legislative requirements for markets where clock time recording and payroll processing are of utmost importance in employee pay. The shift premium and overtime configurations are an essential part of these rules for clients who need to pay their employees based on actual times worked. The features of time valuation and time type groups are very useful in evaluating and segregating the times and making payroll relevant processing rules work correctly.
There are several different industries such as retail. manufacturing. real estate, construction etc. where there are premiums applicable on work performed and overtime payable on extension of work hours outside of the planned work schedule timings.
These requirements usually meander around the standard SuccessFactors Time Tracking solution and hence require the build of configuration logic to achieve the right combination of time type groups and time valuation rules.
Sometimes. a lot of these requirements are quite common in the various markets where the payment of overtime/shift premiums/payroll linked payments etc. take high priority while evaluating an employee's worked hours.
In this blog, I will walk through a similar scenario that was recently encountered for a group of employees who needed to paid a differential OT rate based on certain conditions. This is a very common scenario and I have implemented this multiple times in the erstwhile SAP Time Management (on premise) positive time product. This time around, while implementing it in SF time tracking, I can now vouch for the flexibility and functional robustness provided by this product from SAP launched in January 2021. It is at par in many ways to the traditional SAP on-premise time management product.
Scenario Description
An APAC region client has a scenario wherein the overtime hours worked by their employees are paid at different rates based on the day of the week. Specifically, they need the system to identify if the work done is on a Saturday and/or Sunday and accordingly the OT rates are to be applied in the system to those hours worked. We need to note that the condition here is to be able to decipher the days as being Saturday and Sunday instead of non - working day! So for e.g. if my employee was in fact scheduled to work on a Saturday/Sunday and the hours were booked as per the planned time then no OT is applicable but in case it was outside the planned time, the specific OT rates applicable for SAT/SUN are to be applied. If there are no hours scheduled on Saturday and/or Sunday (ideal scenario) then all the hours need to be accounted as overtime and the correct rates to be applied.
I have also come across scenarios wherein, out of the hours worked on Saturday and/or Sunday, there could be bands during which a particular shift premium also would be included in addition to overtime itself. Some clients also implement the payout of meal allowances that need to be generated in the system for certain shift work on a Saturday / Sunday.
For this blog, I have considered the scenario for payment of OT rates of 250% of daily rate if the employee comes to work on a Sunday. For the purposes of this blog, I have assumed a fixed pattern that has no working hours on Sunday. The rules can be extended/built to consider only the differential hours between planned and recorded working times in case the client does have shift patterns with planned time on Sunday. I have also considered that the shift premium of 175% for any hours worked post 8 PM.
A logical flow diagram for this scenario would be like this:
Configuration Features Used For This Scenario
Before we begin discussing the configuration steps, we need to understand some of the basics of time tracking and how they tie in with the whole solution.
A] Time Records Filter
The major premise of the scenario described above is the identification of the day of the week - is it a Saturday or a Sunday and to use this information to apply the different OT rate accordingly. How would we distinguish the Saturday/Sunday from a normal working day? Here, we will make use of the SuccessFactors Time Tracking feature of Time Records Filter. The time records filter does exactly what its name suggests - it filters the time records to identify whether it is a Saturday or a Sunday. The configuration steps will be described later in this blog.
B] Time Type Groups
Time type groups are basically used in time valuations to either hold the intermediate calculated values from the time valuations or as an outcome of the time valuation for payout to payroll. In short, they are used as variables in a program code that can hold values and continue to process them in further time valuation rules or be part of a counting events etc.
C] Time Valuations
How do you identify and process the input time data such that the employees that record their time inputs through clocks/allowance types etc. are paid correctly? The feature of time valuation takes care of this aspect. Basically, time valuation is like an evaluation of the employee input time data and generates outputs in terms of either time payouts, OT, shift premiums etc. based on the conditions built into the time valuation rules. For the purpose of our scenario and by extension, for shift and OT differential rates & premium payouts purposes, the following main types of valuations, applicable to this scenario, will be useful to know.
C.1] Aggregate Input Group and Split
This valuation type is used when you want to valuate clock times taking into account only the duration of this clock data. For e.g. my employee has clocked in at 9 AM and has clocked out at 6 PM so this valuation type will evaluate the duration between the clock in - clock out recorded by the employee. This valuation type "aggregates" the various input time type groups, applies a threshold value [either a fixed value such as 8 hours or a time type group that contains a threshold value from planned time for example) and then "splits" the records into two main categories.
C1.1] Time type group above & below
Time type groups not fulfilling even one of the criteria will be put into time type group above while those that qualify to the criteria fall into time type group below. For e.g. in case I am checking if the total time worked by an employee is 8 hours then all the input groups falling within this range are put into time type group above while anything within this threshold goes into time type group below. Consider the following example:
| Time valuation type | Threshold value | Comparison against | Input Time Type Groups | Time type group above | Time type group below |
| Aggregate Input Groups and Split | 8 hours | Regular working Time [i.e. scheduled working time] - 9 AM - 5 PM | 8 AM - 9 AM - Internal Training | 8 AM - 9 AM - Internal Training | |
| 9 AM to 1 PM - Normal work | 9 AM to 1 PM - Normal work | ||||
| 1 PM - 2 PM - Lunch Break | 1 PM - 2 PM - Lunch Break | ||||
| 2 PM - 5 PM - Normal Work | 2 PM - 5 PM - Normal Work | ||||
| 5 PM-6 PM - Company Overtime | 5 PM-6 PM - Company Overtime |
C.2] Filter Input Groups & C.3] Filter segments from Input Groups
Filter input groups and filter segments from input groups are both similar, in that they filter the particular day/ segment of work in a day from the input groups and segregate them into time type group below (meets condition) and time type group above (doesn't meet condition). The below example will make it clear.
| Time valuation type | Filter based on | Comparison against | Input Time Type Groups | Time type group above | Time type group below |
| Filter Input Groups | Sunday hours worked | Current Day = Sunday? | 9 AM to 1 PM - Sunday work | 9 AM to 1 PM - Sunday work | |
| 1 PM - 2 PM - Lunch Break | 1 PM - 2 PM - Lunch Break | ||||
| 2 PM - 5 PM - Sunday Work | 2 PM - 5 PM - Sunday Work | ||||
| 5 PM-9 PM - Sunday Shift Work | 5 PM-9 PM - Sunday Shift Work | ||||
| Normal Day hours worked | Current Day = Sunday? | 9 AM to 1 PM - Normal day work | 9 AM to 1 PM - Normal day work | ||
| 1 PM - 2 PM - Lunch Break | 1 PM - 2 PM - Lunch Break | ||||
| 2 PM - 5 PM - Normal day work | 2 PM - 5 PM - Normal day work | ||||
| 5 PM-9 PM - Normal Shift Work | 5 PM-9 PM - Normal Shift Work | ||||
| Filter Segments from Input Groups | Time Segments | Time segments filter - 8 PM to 11:59 PM | Example 1 | ||
| 9 AM to 1 PM - Normal day work | 9 AM to 1 PM - Normal day work | ||||
| 1 PM - 2 PM - Lunch Break | 1 PM - 2 PM - Lunch Break | ||||
| 2 PM - 5 PM - Normal day work | 2 PM - 5 PM - Normal day work | ||||
| 5 PM-9 PM - Normal Shift Work | 5 PM-7:59 PM - Normal Shift Work | 8 PM - 9 PM - Night Premium Shift Work | |||
| Example 2 | |||||
| 9 AM to 1 PM - Sunday work | 9 AM to 1 PM - Sunday work | ||||
| 1 PM - 2 PM - Lunch Break | 1 PM - 2 PM - Lunch Break | ||||
| 2 PM - 5 PM - Sunday Work | 2 PM - 5 PM - Sunday Work | ||||
| 5 PM-9 PM - Sunday Shift Work | 5 PM - 7:59 PM - Sunday Shift Work | 8 PM - 9 PM - Night Premium Sunday Shift Work | |||
Configuration Flow for this scenario of OT on Sunday and Shift Premium Differential Rates
- Firstly we will check if the input recorded working time is on a public holiday or not. This will be done using Filter Input Groups valuation type. The input time type group would be recorded working time which would be the time type group that stores the working time of the employee
This "recorded working time" time type group will include all the inputs that are possible to be recorded by the employee in that particular day as below:
Client Scenario: Check for Overtime Pre-Approval to isolate only approved overtime which matches with recorded overtime clock hours
- In some clients, we have seen a requirement wherein client does not want their blue collar workers to work overtime without informing the manager in advance.
- Also, there are certain cases where the overtime is not paid the the employees unless there is a approval record with the overtime hours cleared with the manager beforehand.
In such cases as point (1) and (2), a attendance time type called overtime is created in the system. Please note that this is a attendance time type as below:
This time type is then added into the "recorded working time" time type group as below:
Once this time type is added into the time type group, it will be part of the accumulation logic for the daily recorded working time classification.
The client can then allow their employee to record the overtime attendance on a particular day [in advance] into this time type and the record can be sent for approval to the manager. Once approved it gets captured into the system for further processing against the clock time recorded on that day. If there are more hours recorded than what has been approved, they will be disregarded and only the hours that the employee works in concurrence with the approved hours are sent for payroll processing. In case the employee works less hours than the approved overtime hours, the lesser of the two is sent for payroll processing. Refer to the table below for clarity on the OT approved for payroll processing.
| OT Pre-Approval Hours [ Overtime Time Type Hours ] | Actual Clock Times [ Clock Times Captured from Employee ] | Overlap between OT Pre-Approval and Clock times worked [ Time Type Group Below ] | Deviation [ Time Type Group Above ] | Final OT Hours sent for payroll processing |
| 5 PM - 9 PM | 9 AM - 9 PM | 5 PM - 9 PM | None | 4 |
| 5 PM - 9 PM | 9 AM - 10 PM | 5 PM - 9 PM | 9 PM - 10 PM | 4 |
| 5 PM - 9 PM | 9 AM - 8 PM | 5 PM - 8 PM | 8 PM - 9 PM | 3 |
Now that we have a holistic understanding of how recorded working times are calculated in the system and how it identifies various segments, let us see how we can now isolate various conditions such as public holiday work and non - public holiday (but Sunday) work.
A] For this purpose, we will first identify the working times that belong to a public holiday and the working times that do not belong to a public holiday.
In order to do so, we will use a time type group above that collects all the worked hours of an employee that do not fall on a public holiday so as to isolate them for further conditional checks such as working hours on Sunday.
| Recorded Working Times [Recorded Working Time (WORK_REC)] | Current Day = Public Holiday? | Time Type Group Below [OT@2.5_1 (OT@2.5_1)] | Time Type Group Above [NPH_INP (NPH_INP) ] |
| 5 PM - 9 PM | No | 5 PM - 9 PM | |
| 5 PM - 9 PM | Yes | 5 PM - 9 PM |
B] In order to filter out the public holiday hours, we will use the time records filter feature in the time valuation rule as below:
The time records filter can be used for a variety of conditions such as PH & non - PH checks or day of the week checks. For the check on PH work hours, the below time records filter will suffice.
C] The non - PH work hours have been successfully segregated from the non - PH work hours using the above valuation rule. Moving ahead, we will now use the input time type group as the non PH work hours isolated above [Time Type Group NPH_INP] as the reference to isolate the work hours on Sunday.
This will be achieved by first creating a time records filter that checks if the day being evaluated is a Sunday and if yes, it will be segregated into a different time type group below as shown here. Since the requirement is to pay the overtime of an employee for Sunday at 250% - we will name the time type group accordingly.
| Non PH work hours [Time Type Group NPH_INP ] | Current Day = Public Holiday? | Current Day Sunday? | Time Type Group Above [NPH_MON_SAT_INP (NPH_MON_SAT_INP ] | Time Type Group Below [OT@2.5_2 (OT@2.5_2)] | Hours sent for payroll processing |
| 9 AM - 6 PM | No | No | 9 AM - 6 PM | ||
| 9 AM - 1 PM | No | Yes | 9 AM - 1 PM | 4 |
C.1] Segregate Sunday hours from the Non PH hours from step B
Note that we are using the time valuation rule type as Filter Input Groups - this means that we are filtering the Sunday work hour records from the overall non - PH work hours collected in the previous time valuation rule. The time records filter is again used here so as to filter the day of the week and isolate the Sunday working hours only. These are to be paid at a rate of 250% of the daily rate and would serve to hold the hours to be sent to payroll for further payment processing.
Since we would like the hours (OT @ 250%) be paid through payroll - we will mark this as a time pay type as below:
D] Filtering time segments in a day to ascertain shift premium differential rates
Coming to the requirement on the payment of late night shift premium at 175% to employees who work from 8 PM to mid night, we will use the concept of the time valuation rule type - "Filter Segments from Input Time Groups"
Essentially what this entails is as below:
| Input Time Type Group - Recorded Working Time (WORK_REC] | Time Segment Filter | Time Type Group Below - Late Night Premium (175%) | Hours sent for payroll processing? |
| 9 AM - 6 PM | None | None | No |
| 9 AM - 10 PM | 8 PM - 10 PM | 2 | Yes |
| 12 PM - 11:50 PM | 8 PM - 11:50 PM | 3 Hours 50 minutes | Yes |
In this case, there will be no distinction on the day when the OT is worked in late night shift. (See below scenario for further segregation based on the day of the week = Sunday)
In this case too, as above with the OT hours, we categorize the time type group "Late Night Premium Pay" as time pay type for payout in payroll processing as below:
In case your business scenario is to pay the late night shift premium only for Sunday hours (OT worked on Sunday) then instead of using the input time type group WORK_REC, you can use the input time type group as Sunday OT@2.5% which we created in the time valuation rule for Sunday work hours and then use the time segment filter for the hours from 8 PM to 11:59 PM to further ascertain how many hours to be paid at 175% premium rate over and above the 250% OT rate.
| Input Time Type Group - OT@2.5% (Sunday Work Hours) | Time Segment Filter | Time Type Group Below - Late Night Premium (175%) | Hours sent for payroll processing? |
| 9 AM - 6 PM | None | None | No |
| 9 AM - 10 PM | 8 PM - 10 PM | 2 | Yes |
| 12 PM - 11:50 PM | 8 PM - 11:50 PM | 3 Hours 50 minutes | Yes |
Conclusion
SuccessFactors Time Tracking has introduced many different features and enhanced the product to cater to various complex and legislative requirements for markets where clock time recording and payroll processing are of utmost importance in employee pay. The shift premium and overtime configurations are an essential part of these rules for clients who need to pay their employees based on actual times worked. The features of time valuation and time type groups are very useful in evaluating and segregating the times and making payroll relevant processing rules work correctly.
- SAP Managed Tags:
3 Comments
