Managing Recurring Pay Components in SuccessFactors Using Batch Upsert

[ankitkumarpatel]

Introduction:

In this blog, we will delve into the intricacies of managing recurring pay components and explore their implications if they persist beyond specific events such as employee rehires. Understanding and effectively managing recurring pay components are crucial for seamless payroll processing and mitigating potential unwanted consequences.

In the realm of integration scenarios, where SuccessFactors Employee Central portlets are managed and updated through third-party systems via Inbound Integration, the utilization of CPI as a middleware can sometimes lead to overlooked compensation updates. This blog addresses the use of CPI to effectively delimit previous non-effective pay components, particularly in the context of rehires.

Why Rehires?

Rehires present unique scenarios where updates to employees' employment, job, or compensation details render previous information obsolete. When records are populated or updated from a third-party system into SuccessFactors, the job or compensation record may be updated with the rehire event, thereby overwriting previous history. However, in the case of recurring pay components, the previous pay component may carry forward to the new event. While the pay components may be valid for the new event in some cases, the automatic propagation of recurring pay components can result in financial discrepancies in payroll processing. This can lead to overpayment or incorrect payment to employees due to the inclusion of both new and previous pay components in the compensation calculation.

The image below illustrates the behaviour of recurring pay components with changes in each event for an employee. If pay components are not end-dated, they continue to forward propagate even after a rehire event, as highlighted in red below. These pay components may become invalid with effective dated changes, yet they persist due to lack of manual intervention or automation. Consequently, managing updates to pay components or delimiting those no longer valid for an employee becomes crucial, especially if payroll is linked with SuccessFactors Compensation Information

Fig 1. Pay Component Recurring with Event Changes

The Delimiting option for Pay Component Recurring is demonstrated in below sections considering CPI (Inbound Integration) as a middleware, source system as Third-Party system and target system for payroll as SuccessFactors.

Problem Statement:

Delimiting and Handling Pay Component Recurring portlet updates and forward propagation.

Resolution:

The resolution for this issue may vary depending on data policies and compliance in SuccessFactors. However, it can be addressed within the integration itself and automated for efficiency. By utilizing event or event reasons from source systems, changes in pay components under Compensation information can be identified. In the case of a rehire scenario, where pay components might be updated, this approach becomes particularly relevant.

 To handle compensation and pay component recurring information during a rehire, all pay component recurring records can be delimited. This action wipes out pay components associated with base salary, incentives, variable pay, benefits, bonuses, etc. Subsequently, the rehire panel updates are added to the Compensation information. To illustrate this process, let's refer back to the example introduced in the introduction.

Fig 2. Delimiting Pay Components before Rehire event update

On the left side, we have the event changes for an employee under 'Employee Event Changes,' while the pay component recurring changes, i.e., Compensation Information event changes, are depicted on the right side.

For instance, at the time of termination, the employee had five pay components: Base Salary, Car Allowance, Meal Allowance, Accident Insurance, and Transportation. However, these pay components become non-eligible for future payroll consideration upon rehire, effective as of February 01, 2024. Despite this, due to forward propagation, these pay components may persist and get added with the new event changes in compensation information, as shown in Figure 1.

To address this issue, a batch upsert operation with the DELIMIT operation can be performed. Below is the payload used for the upsert operation

<batchParts>
    <batchChangeSet>
        <batchChangeSetPart>
            <method>UPSERT</method>   <uri>EmpPayCompRecurring(payComponent='CAR_DE',startDate=datetimeoffset'2024-02-01T00:00:00',userId='mjones',seqNumber=1L)</uri>
            <EmpPayCompRecurring>
                <EmpPayCompRecurring>
                    <payComponent>CAR_DE</payComponent>
                    <seqNumber>1</seqNumber>
                    <userId>mjones</userId>
                    <frequency>Monthly</frequency>
                    <paycompvalue>20</paycompvalue>
                    <currencyCode>EUR</currencyCode>
                    <startDate>2024-02-01T00:00:00</startDate>
                    <operation>DELIMIT</operation>
                  </EmpPayCompRecurring>
            </EmpPayCompRecurring>
        </batchChangeSetPart>
    </batchChangeSet>
</batchParts>

 Payload for DELIMIT in pay comp recurring via Batch Upsert

Similarly, the payload is prepared for all pay components. After running the Integration in CPI, the pay components are wiped out as shown in the Fig 2.

Fig 4. SF panel after Delimiting Pay Components

Once all the pay components are removed, we can now insert the new ones with Upsert (POST) method in CPI using SuccessFactors ODATA V2 adapter, the payload for the UPSERT is shown below for reference,

<batchParts>
    <batchChangeSet>
        <batchChangeSetPart>
            <method>UPSERT</method>
  <uri>EmpPayCompRecurring(payComponent='BASESAL_DE',startDate=datetimeoffset'2024-02-01T00:00:00',userId='mjones',seqNumber=1L)</uri>
            <EmpPayCompRecurring>
                <EmpPayCompRecurring>
                    <payComponent>BASESAL_DE</payComponent>
                    <seqNumber>1</seqNumber>
                    <userId>mjones</userId>
                    <frequency>Monthly</frequency>
                    <paycompvalue>7000</paycompvalue>
                    <currencyCode>EUR</currencyCode>
                    <startDate>2024-02-01T00:00:00</startDate>
                  </EmpPayCompRecurring>
            </EmpPayCompRecurring>
        </batchChangeSetPart>
    </batchChangeSet>
</batchParts>

Payload example for creating Pay Components in SF via Batch Upsert

After running the Integration in CPI, the new pay components get added to the Rehire panel under Compensation as shown below,

Fig 6. Compensation after adding Pay Components via Batch Upsert

Conclusion:

Updating and maintaining pay components is essential to ensure accurate payroll-related information remains available for clients. In scenarios where SuccessFactors is not the source of data, dependency on other systems for accuracy persists. This blog sheds light on the relationship between compensation events and pay compensation changes, particularly during major event changes, and their impact on salary calculations. Similar approaches can be adopted to address other scenarios not covered here. Thank you for taking the time to read through this blog.