Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
eeshwari
Participant

Introduction

This blog is a continuation of my previous article where I have explained in detail on how to automate the absence creation in SuccessFactors Time using the capabilities of the integration center. You may want to read through it before we go through this blog since I would reference a lot of configuration parts that are explained in detail in that article. You can read it here.

The question that came up after the community went through the blog was - "How do we send the cumulated time collector values to payroll as SF Time Tracking does not allow for a time collector to be an input group to generate a time pay type nor are you able to assign a time collector as also a time pay type group"

The answer lies in the fact that we cannot look at SF Time Tracking as a standalone product. SAP has designed it intelligently to work together with the Employee Central Payroll module. The capabilities we seek are inherent to these two solutions and need to be leveraged as such. However, while I detail both the approaches to send the values to EC payroll, the focus of this blog is to explain how to auto-create a time pay component into the one time payments portlet in EC and thereby allow for the standard PTP replication to take over and send to payroll for a payout. 

We are going to explore the possibilities of using time collectors to send the cumulated values to payroll or to send the time pay types to payroll and cumulate there. The technical flow diagram is as below:

flow diagram.png

Scenario:

Let us take a simple client scenario wherein whenever an employee is late to work / leaves early from work, the system needs to send the late coming/ early leaving hours to EC Payroll for deduction. Simple, isn't it? I will explain both the solutions - wherein, the hours are sent to EC Payroll as soon as they are created in terms of the time pay types upon time valuation and also if we want to cumulate them into a time collector and then send them across to payroll. 

Firstly, lets tackle the generic steps that are used to create the time pay types and the time collector values in SuccessFactors Time Tracking module. 

Recap from my previous blog - Technical Solution Steps to achieve the above client scenario

Step 1: Create a Time Recording Profile:

In Manage Data – create a time recording profile with positive time recording method and a time recording variant of clock times

10.png

 Step 2: Create time type groups for planned working time, recorded working time and to hold the difference between the planned and recorded working times

Step 2.1: Create time type group for planned working time

2.png
Step 2.2: Create time type group for recorded working time

3.png
Step 2.3: Create time type group to hold the difference between planned and actual working time

4.png
Step 3: Create a valuation rule to calculate the difference between the planned and recorded working time for identifying the gaps between the planned and recorded working time of an employee

5.png
Step 4: Create a time type group that would be used to identify the gaps within the start of recorded working time and start of the planned working time.
6.png
Note: A time collector will be used to store this value for creating an automatic one time payment through integration center to showcase the technical ability for sending the cumulated value to Employee Central Payroll

Step 5: Create a valuation rule that will filter the gaps between the start of the planned working time and the recorded working time.

eeshwari_0-1710571442299.png

Step 6: Create a time type group that identifies the gaps in the end time of the planned and recorded working times and collects it for auto creation of a one time payment through integration center

8.png

Step 7: Create a valuation rule that will filter the gaps between the end of the planned working time and the recorded working time.

9.png

Step 8: Assign the time valuation(s) to the time recording profile of the employee along with the other rules that may already be assigned to the time recording profile.

10.png

Step 9: Assign time recording profile to employee in job information.
Once the time recording profile is assigned to the employee in job information, the time collector value is created after the time sheet entries are made to reflect the scenario of late coming or early leaving.

Options to send the hours to payroll for further processing

Now, let us tackle the two options of the deductions in payroll for the late coming / early leaving. 

A] Time Pay Type containing the difference in the planned versus recorded start/end times sent to EC Payroll basis the time valuation results without the need to use cumulated value in the time collector

This is a simple straightforward solution where the time pay type created with the difference in the planned versus recorded time is pushed to EC Payroll for deduction. In case, there is a limit on the deduction amount per month then it can also be ensured by using the DDNTK functionality and pushing the excess deduction into the following month or generating a claim in the termination month etc. If there is a requirement to check on the quarterly late coming / early leaving hours and alert the payroll manager on the anomaly through validation rules in the payroll control center (PCC), the cumulation can be designed using V_T54C3 table and applying a quarterly cumulation with the resultant wage type being pulled into a customer specific notional result table wage type that can be used for the PCC alerts. 

I would like to highlight a specific scenario where a client's legal requirement is to check for a quarterly overtime capping of 108 hours.

We indeed have a limitation on the quarterly cumulation ability of time collectors and hence the EC Payroll solution is more suitable - the overtime time pay types can be cumulated on the payroll side, the order of capping (highest OT rate to be considered last for capping and the lowest OT rate to considered first for the capping check) can be applied accordingly and then the payment for the overtime can be made in accordance to the 108 hours rule.

We therefore, leverage on the cumulation capability in EC Payroll in V_T54C3 table as below for the various OT wage types. Basis the scenario and design details, you can also use a single wage type that contains the total OT hours for the employee to check against the 108 hours capping - then again, if the capping has priorities based on the payment rates then the below set up will be more ideal. 

eeshwari_0-1709432992294.png

The payroll side PCR for this would roughly look like this with complexity increasing as the various business scenarios are applied to it.    

eeshwari_1-1709436828699.png

B] Option of sending the cumulated time collector value to payroll through auto creation of the one time payment component in the EC portlet and PTP replication

For the configuration steps for the integration center mapping, please refer to the steps I have already documented in my previous blog here

Field Mapping

We will map the time collector fields created in time valuation to the one - time payment  (EmpPayCompNonRecurring) fields (most important ones) as below: 

eeshwari_0-1710568423222.png

Here the pay component has been hard coded as "1111" (which is nothing but the payroll code for the wage type that will then be mapped in the ECP system for the IT 15 input) for this example but this can also be dynamically picked and used basis a lookup created for client specific requirements. This lookup can be used in scenarios where an employee with a different personnel sub area may need a different code. Mind you, this can be segregated in the EC Payroll side in the payroll schema during payroll run. The reason we mention it here is to highlight the technical feasibility of the requirement in SuccessFactors Integration Center + SuccessFactors Time Tracking product. 

eeshwari_1-1710568901528.png

eeshwari_0-1710571946040.png

You can also apply the conversions from minutes to hours etc. in the calculation section of the integration center. The integration set up now is completed as below:

eeshwari_1-1710572074014.png

A sample run will show you the below output for the required employee - this will be the result of the Integration Center job and this will auto create a component in the employee's EC portlet based on the time collector value. 

hours .png

Hence, based on this Integration Center job that will be scheduled, the time collectors will be used at the end of the frequency period to auto create the hours into a one time payment component for the employee in EC. In our example, this result of 20 will need to reflect in the employee's pay component portlet. 

In this example we have mapped to the amount field but the time collector value can also be mapped to the number field. The payment or deduction definition can also be managed in EC Payroll; essentially the sending of this one time payment to payroll is handled through integration center while the payment/deduction logic can be ascertained basis the scenario use case itself. 

Outcome of the Integration job run therefore creates the 20 units pay component record - wage type 1111 - as below in the EC portlet: 

eeshwari_2-1710572390740.png

Conclusion:

There are technical design decisions to be taken by the solution architect on which approach to use and which one's a cleaner design but this blog highlights both the options and provides insights on how to use the capabilities of SF Employee Central, SF Time Tracking, SF Integration Center and SF Employee Central Payroll understanding that all these need to work together seamlessly to ensure the client requirements are met flawlessly.  

3 Comments
Labels in this area