To start with the basic programming terminology "Hello World" always make the podium ready for something to interact. And the secret is that, programming is my first love. So I pick this word for you to start with.
Since quite some time now, I wanted to write my first blog on SuccessFactors to share the joy I got while achieving some challenging functionality indulging few precious things, like "Time", "Energy", "Concentration", "Explore".
Today, I will share with you, a specific business scenario and the how to cater that. We were implementing SuccessFactors for our beloved customer, in an integrated environment. Almost all modules were to be implemented including Employee Central (EC) and Employee Central Payroll (ECP). I mentioned it as integrated environment, as there were multiple third party systems involved and as a result, multiple interfacing was to configure to cater the data flow requirement between SuccessFactors and third party systems. We were using ODATA services to cater the interfacing requirement with SuccessFactors.
In one of such scenario, the requirement was to cater a data flow from a third party system to SuccessFactors master data (Employee Central) and the subsequently, flow to Payroll Process (Employee Central Payroll). Specifically, my client was providing an optional Car Parking Facility to their employees, against a moderate monthly charge. Enrollment and withdraw formalities were maintained via a third party Car Parking Tool/software. Employees were allowed to avail this functionality for a period or continuous service. So either they needed to inform the start and end of the usage of the facility or they can just start using the facility and continue availing the same till further notice. Availing this facility incurred a cost factor that were getting deducted from their monthly remuneration. Before SF implementation, the charges for employee Car Parking usage, were manually feed to their payroll, on monthly basis to based on an excel file provided by the third party tool mentioned.
So their requirement was to automate this deduction process and to develop an interface between Car Parking System to SF Employee Central and then pass the deduction charges to Employee Central payroll for Payroll processing. One additional requirement, that were asked for this new solution were to auto calculate the car parking deduction amount (varied based on employee type and annual entitlement) based specific business criterion that were to be identified via parameter passed from third party while interfacing the data. Clearly the calculations were to be done at Employee central end.
Since we were using ODATA API to cater all integration scenario as mentioned, solution for the requirement that came to my mind, was to create the Recurring Monthly Pay Component, via ODATA API call and update the deduction amount, via a business rule (save rule) at the time of Pay Component saving and then replicate the pay component to ECP, as standard process. Pay components were to convert into deduction wage types at ECP end so as to pick via payroll process.
Solution sounds simple isn't it? But, as usual, the hurdles keep coming when I actually started implementing it. The immediate concerns were to:
Identify the API/API's to create the pay component (not straight forward way to just create a pay component calling one API)
How to remove the deduction pay component when user opted out the car parking facility?
Will save rule trigger with ODATA API call?
There were few more queries and alternate approachs as well, but not mentioning those. Hey, friends, I am not hearing anything from you, yet. Are you not interested? Shall I stop here? Are you finding this boring?
Oh, I forgot this is blog time and not an interactive session. Well, let me finish quickly and wait to hear from you in the form of comments.
So, I explored a lot, take help from different forum, got some clue and went with my trial and error and yes, finally got the resolution and here is the step by step process:
Firstly, the API identification:
First point that I learn that, you can't directly create a Pay Component in EC. You have to incorporate your pay component inside a Compensation Information. So, I created Compensation Information (API - EmpCompensation, Operation - Upsert) with begin date as the entry date provided in the third party interfacing XML for the car parking deduction, end date as HR end date (99991231) with Event Reason as "Car Parking Deduction Update".
Then I created the required Pay Component (you have to configure specific pay components based on your requirement, I configured "Car Parking Deduction Update" pay component beforehand), with begin date and end date same as above (API - EmpPayCompRecurring, Operation - Upsert)
So, the pay component is ready for recurring monthly deduction.
Second hurdle, how to cater the removal of deduction:
The question was, what are the all possible deduction scenario? from the business requirement already mentioned, two possibilities. Either employee has to mention the star and end date of deduction. Say, someone wants to avail the facility for a month or 6 months, or they will not mention any end date with the intention to stop it on demand.
So, how to identify this based on the information that comes from third party Car Parking System? Simple, with end date provided in the interfacing XML from them. So the assumption is if an employee wants a continuous service of parking their cars, they will mention the start date only or if they want a periodic usage, they will mention start and end date of the usage and lastly if an employee wants to stop the continuous service they are availing, they just need to mention the end date of the service. Hence the inbound excel contains end date accordingly.
Ok! Ok! So, I had the required information. Now, how to place this? So what I did was to make use of "Delimit" functionality of Employee Central component information.
So there three cases, mentioned has been implemented leveraging IF, ELSE conditions, while calling ODATA API's via HCI middleware.
If only Start Date provided in the third party interfacing XML, create a compensation information (using API - EmpCompensation) and Recurring Pay Component (Using API - EmpPayCompRecurring) with start date as third party XML interface start date and end date as HR end date (99991231)
If both Start and End Dates provided third party interfacing XML, then create a Compensation Information (using API - EmpCompensation) and Recurring Pay Component (Using API - EmpPayCompRecurring) with start date as third party XML provided start date of parking usage and end date as HR end date (99991231). Then for future end of deduction amount, create another compensation information (API - EmpCompensation) with start date as the end date (future dated) provide in the third party XML interface and end date as HR end date (99991231). Then create a Recurring Pay Component Information (API - EmpPayCompRecurring) mentioning Operator as "DELIMIT" against the pay component ID for "Car Parking Deduction" amount update. This will remove that specific Recurring Pay Component from that future date keeping other Pay Components (e.g basic etc) intact
In last possible scenario, say user was availing the car parking facility and now they don't want to continue, hence they informed the third party and third party sends a interfacing XML with end date only to the middleware (HCI) to trigger the ODATA API to update information in EC accordingly and to replicate to ECP subsequently to stop the deduction from payslip. Compensation Information (using API - EmpCompensation) with start date as third party XML provided end date of deduction amount and end date as HR end date (99991231). Then create a Pay Component Information (API - EmpPayCompRecurring) mentioning Operator as "DELIMIT" against the pay component ID for "Car Parking Deduction" amount lodging with same start and end date. This will remove the deduction pay component, and will replicate the ECP accordingly
So, we arrived at the last and critical part of the scenario, to trigger save rule while updating pay component information via ODATA API call.
So, what was the requirement initially, to update the Recurring Pay Component created via ODATA API, with actual deduction amount based on master data with specific business logic. How to do this? The best and optimize way is to use business rule (On save). But, when I created the business rule, and attach this at "On Save" event at Pay Component Recurring, the rule didn't trigger at all, but Recurring Pay Component got created successfully.
So, what next? Will it work? Do we need to think of another approach? Shall we connect SAP? Queries, queries!
And again, I started buzzing forums, fiends, interstate. I got feedback from many forums that, business rule doesn't work with ODATA API. I was puzzled. But keep on trying.
And, yes my friends, what I explored out is that, business rules do work with ODATA API as well. But you need to know the trick. You have to provide an additional access to your ODATA API calling user to trigger business rule while updating compensation information.
To cater this requirement, access Permission Roles, assigned to the user, go to the head, "Employee Central Import Settings" to the left navigation, select, "Compensation Information" from the list mentioned under the header "Enable Business Rules for selected areas" from the right view. It worked properly after that and save rule triggered with data creation.