SuccessFactors Employee Central Global Benefits – Automating Employee Claims (Voucher Benefits)

Introduction

In this blog post, I will be sharing some design concepts for Employee Central Global Benefits implementation and how to configure them.


Scenario: When the employee has a newborn child or on birth date anniversaries; the employee automatically claims an eligible benefit. The employee receives a voucher code from the system or gets paid based on an entitlement amount. (or both)

Solution: There are multiple ways to approach this scenario to create a solution but for this blog, I will be choosing the below method;

  1. Create Benefits such as “Newborn Voucher”, and “Birth Date Voucher” with Reimbursement type (for each currency we will have)
  2. Select “Integration Mode” as “Pay Components” or “Benefit Objects”. If a one-time payment needs to be created the selection should be “Pay Components”. As a pre-requisite, you should create the “Pay Component” beforehand. You can refer to the implementation document.
  3. Create the “Eligibility Rule” based on your scenario or put a fixed value under the entitlement amount.
    I will utilize the “Currency Exchange Rate” table to exchange the rates based on the Benefits’ selected currency inside the eligibility business rule. If you want to follow the same method, I would suggest you create an index table (custom MDF object with an effective date) to store entitlement amounts so that it is easier to maintain the values yearly/half yearly.
    Also, with this method, you are generalizing the eligibility rule logic for all of the Benefits of that specific type and you can use the same business rule for all.
    In some cases, company policy dictates an entitlement amount to be used in a central foreign currency but this value generally gets converted into local currency. (to process within payroll)
  4. (Optional) Create a custom MDF object to store voucher vendors. (country, vendor name, etc.)
  5. Create a custom MDF object to store voucher-related details. (vendor name, voucher code, amount, voucher validity start and expiry dates, etc.)
  6. Create a custom MDF object to propagate voucher details into the “Benefit Employee Claim” records. You can refer to the implementation document. (Disclaimer: When custom objects are being used under Benefits, mobile application functionalities will not be available)
  7. Select the “Trigger Event” as “Child Birth” or “Date of Birth” depending on the scenario.
  8. Select your currency and do not maintain any schedule or workflow values.
  9. Create a sequence record starting from 1 and a step value of 1. This sequence will make sure that employees never receive a voucher code for a second time.
  10. Create a business rule to set voucher details on the Benefit Employee Claim record. (on Save business rule)

Pre-requisite: An intermediate level of knowledge on how to work with MDF objects, implement Employee Central, work with business rules, and set up Global Benefits is required. Please consider checking referenced additional materials and information. (at the bottom of the blog)



Solution Step-by-Step Guide

Step 1: Create all of the custom MDF objects, picklists, pay components, and custom MDF object data records.

  • Create the “Sequence” record:

Sequence%20for%20Voucher%20Code%20Generation%20Control

Sequence for Voucher Code Generation Control

  • (Optional) Create the “Currency Exchange Rate” records:

Currency%20Exchange%20Rate%20Record%20for%20USD%20to%20EUR%20Conversion

Currency Exchange Rate Record for USD to EUR Conversion

  • (Optional) Create the “Pay Component” record:

Pay%20Component%20for%20Newborn%20Voucher%20Payment

Pay Component for Newborn Voucher Payment

  • (Optional) Create the “Benefit Eligibility Lookup/Index Table” MDF object: The design of this object may vary based on your requirements.

Benefit%20Eligibility%20Lookup%20Table%20-%20Object%20Definition

Benefit Eligibility Lookup Table – Object Definition

  • (Optional) Create the “Benefit Eligibility Lookup/Index Table” MDF object record(s): In my design; as a pre-requisite, the related “Benefit” record already needs to be created to create the lookup table record.

Benefit%20Eligibility%20Lookup%20Table%20-%20Newborn%20Eligibility%20Lookup%20Table%20Record

Benefit Eligibility Lookup Table – Newborn Eligibility Lookup Table Record

  • (Optional) Create the “Voucher Vendor” MDF object: The design of this object may vary based on your requirements.

Voucher%20Vendor%20-%20Object%20Definition

Voucher Vendor – Object Definition

  • (Optional) Create the “Voucher Vendor” MDF object record(s):

Voucher%20Vendor%20-%20Data%20Record

Voucher Vendor – Data Record

  • Create the “Voucher Details” MDF object: The design of this object may vary based on your requirements.

Voucher%20Details%20-%20Object%20Definition

Voucher Details – Object Definition

  • Create the “Voucher Vendor” MDF object record(s): While uploading the “Voucher Details” data records, system admins should set “Current Sequence Number” with a unique value for each of the data records. While getting the next value from the “Sequence”, the lookup function will cross-check the generated sequence value with the data uploaded. You can assign “cust_currentSequenceNumber” as a “Business Key” inside the object definition, this will make sure all the data inside this field will be unique.

Voucher%20Details%20-%20Data%20Record

Voucher Details – Data Record

  • (Optional) Create the “Benefit Voucher Details” MDF object: After creating the object definition, it needs to be assigned under the “Benefit Employee Claim” object definition as a new “Composite” “One to One” association.

Benefit%20Voucher%20Details%20-%20Object%20Definition

Benefit Voucher Details – Object Definition

Benefit%20Voucher%20Details%20-%20Example%20Child%20Record%20under%20Benefit%20Employee%20Claim

Benefit Voucher Details – Example Child Record under Benefit Employee Claim

Step 2: Create all of the Benefit records:

  • Create Benefits such as “Newborn Voucher”, and “Birth Date Voucher” with Reimbursement type (for each currency you will have)
  • Select “Benefit Type” as “Reimbursement”.
  • Select “Integration Mode” as “Pay Components” or “Benefit Objects”. If a one-time payment needs to be created the selection should be “Pay Components”.
    As a pre-requisite, you should create one “Pay Component” as shown above. Also, you can refer to the implementation document.
    Necessary pay component edit permissions need to be granted to the employees for them to create one-time payments.
  • Create the “Eligibility Rule” based on your scenario or put a fixed value under the entitlement amount.
    • First, assign the necessary variables if you are going to use “Currency Exchange Rate” and convert the entitlement amount.

Eligibility%20Rule%20-%20Variables

Eligibility Rule – Variables

    • Last, put your if/else logic. You will need “Else” because you are not allowed to create a “Currency Exchange Rate” record having the same “Source” and “Target” currency.
      It is recommended that you put the “Treat Null As()” function control for your lookup outputs.

Eligibility%20Rule%20-%20If%20Else%20Logic

Eligibility Rule – If Else Logic

  • Select the “Trigger Event” as “Child Birth” or “Date of Birth” depending on the scenario.
    • When “Date of Birth” is selected, you will need to create the respective “Provisioning Job” to create “Benefit Employee Claim” records. You can refer to the implementation document to create and schedule this job.
    • When “Child Birth” is selected, the employee needs to add a new dependent record into “Employee Central Person Relationship Info HRIS Element” with a “Relationship Type” of “Child” (standard relationship type picklist and values are a requirement), and a “Date of Birth” value.
      If there is a workflow as per the EC configurations, the “Benefit Employee Claim” record will be created after the HRIS Element record gets approved and a one-time payment will be created on the approval date. (as payment date)
  • If you created the “Benefit Voucher Details” object, it needs to be selected under “Additional Claim Fields”.
  • Select your respective currency and do not maintain any “Benefit Schedule” or “Claim Workflow” / “Exception Workflow” values.
  • If you created the eligibility rule, assign the respective one under “Eligibility Rule”.
  • Maintain other mandatory fields. (ex. “Legal Entities”, “Benefit Name”, “Benefit Code”, “Effective From”, etc.)

Step 3: Create the business rule logic to populate voucher details inside the “Benefit Employee Claim” records and assign it as an “on Save” rule under the “Benefit Employee Claim” object definition.

  • Create the “Eligibility Rule” based on your scenario.
    • First, assign the necessary variables, this is important because we don’t want to call the “Get Next Value()” function more than once per the “Benefit Employee Claim” record creation scenario. (this will increase the current number value inside the “Sequence” record)

Benefit%20Voucher%20Details%20-%20Business%20Rule%20Variables

Benefit Voucher Details – Business Rule Variables

    • Last, set your If/Else logic.

Benefit%20Voucher%20Details%20-%20Business%20Rule%20If%20Else%20Logic

Benefit Voucher Details – Business Rule If Else Logic

Step 4: Generated “Benefit Voucher Details” can be tracked inside the “Recently Approved Claims” records by clicking the claim records.
Employee Profile – Go To Benefits – Reimbursement, Recently Approved Claims (remember, this UI can be customized under “Benefit” data configuration settings)

Go%20To%20Benefits%20-%20Reimbursement%2C%20Recently%20Approved%20Claims

Go To Benefits – Reimbursement, Recently Approved Claims


Some other enhancements which can add to this implementation scenario are;

Daily SF-SF internal integration to update “Voucher Details” validity via the Integration Center

If we were to create a daily scheduled integration as;

Source: SF Odata Voucher Details

Target: SF Odata Voucher Details

Create a business rule which will use the lookup function to check whether the voucher code is used inside any of the “Benefit Voucher Details” (claim records) or not; If it is used, the rule will set the “Validity” field under the “Voucher Details” object as “False” (boolean field) else as “True”.

This will help the admins to track voucher usage throughout the system.

Daily SF-SF internal integration to update “Voucher Details” validity via the Integration Center

If we were to create a daily scheduled integration as;

Source: SF Odata Benefit Voucher Details

Target: SF Odata Employee Voucher Details (This is a user-based custom MDF object which has a “One To Many”, and “Valid When” association)

With the help of the above integration, when it is scheduled with the multiple executions per day scenario, employees can see their voucher details more fashioned way.

Employee%20Profile%20-%20Employee%20Voucher%20Details

Employee Profile – Employee Voucher Details

Voucher assigning based on employees’ vendor decision

If we were to create above scenario;

  • When an employee selects “Voucher Vendor” under “Employee Voucher Details”, with the help of a minor change under the business rules, the system can look up and assign the voucher based on their decision.

Advanced or Story reports analyzing overall “Voucher” payments and usage

If we were to create some reports inside the system;

Compensation, Spot Award business teams, or HR analytics teams can make an analysis of the distribution of the “Voucher” records to fetch the total cost for the employer, and overall voucher usage during the reporting period to decide whether to increase or decrease the value of the purchase on Vendor side, etc.

Enhancing the scope of the solution

Lastly, these automated scenarios can be increased to cover all of the necessary personal or employment-related life events. (such as promotion, transfer, hire, rehire, marriage, etc.)
Some of them may require extensive knowledge of other configuration details. (make sure to check reference URLs at the bottom of the blog)


In conclusion, there are various alternatives to satisfy the requirements when it comes to Global Benefits and automating processes. (Life Events, Auto Enrollments with Employee, and Benefit Master Data Change Trackers, etc.)

So, I hope the above scenario will help you to satisfy customer requirements on your implementation journey.

Thank you for taking the time to read and please do not hesitate to leave your comments below for any questions!


You can also refer to the official SAP documentation below on how to accomplish some of the mentioned points above;

SAP SuccessFactors Employee Central – Useful Resources and Documents

Implementing Employee Central Core

Implementing Global Benefits

Implementing the Metadata Framework (MDF)

Intelligent Services Center

Integration Center