Introduction:
During my investigation, I actively searched for a conventional solution to address a scenario resembling trigger-based accrual in SuccessFactors. Recognizing that SuccessFactors lacks the functionality for trigger-based accruals, I put in my efforts to discover a suitable alternative solution and craft a workaround to meet the customer's requirements, rather than simply delivering a discouraging 'No' as a response.
Requirement:
The main goal is to implement a dynamic accrual system for the "Bank of Holidays" time account based on employees' vacation submissions from their "Vacation" time account. There are specific conditions to consider:
- Employee's "Vacation" time account accrues 25 or more days annually (this can be designed with available accrual rule), and the initial balance of the "Bank of Holidays" time account is zero.
- If an employee submits a vacation request for 5 or more days during the months of January, February, March, November, or December (referred to as JFMND), the system should credit 2 days to the "Bank of Holidays" time account.
- If an employee submits a vacation request for 5 or more days during the months of April, May, June, or October (referred to as AMJO), the system should credit 1 day to the "Bank of Holidays" time account.
- Only the first vacation request of 5 or more days within the respective sequence of months is considered. For instance, if an employee submits 5 days in February and another 5 days in March, the system should credit only 2 days (from the February request) for the JFMND months and not 4 days (2+2).
- Similarly, for the AMJO months, only the first vacation request of 5 or more days within that period will be considered for accrual.
- Consequently, the maximum accrual for the "Bank of Holidays" should not exceed 3 days at any given time. This means a maximum of 2 days for JFMND months and a maximum of 1 day for AMJO months.
Solution:
To address the outlined requirements, I devised a comprehensive solution that leverages intelligent services in combination with Integration programs and makes use of the daily accrual frequency of the time account. The main steps involved in implementing the solution are as follows:
- Time Account Setup:
We introduce a new time account type called "Bank of Holidays" with a daily accrual frequency to facilitate accrual calculation for vacation time. The specific details of the accrual rule for this account type will be explained later in the process.
- MDF Object Creation:
We create an MDF object named 'Spain Bank of Holiday LookUp' with multiple fields. The onSave rule is designed to populate the "Accrual Eligible Year" as required, as shown in the illustration.
- Modification of Intelligent Services Rule:
The standard intelligent services rule 'SAP_EVENT_LOASTA' is assigned as onSave under the Employee Time object. We modify this rule to trigger the event for employee vacations lasting five or more days, based on specific conditions.
- Integration Flows:
We introduce two integration flows named ECTIME_ESP_BOH_1DAY_ACCRUAL and ECTIME_ESP_BOH_2DAY_ACCRUAL to handle 1-day and 2-day accruals for specific months, namely AMJO and JFMND.
- Accrual Eligibility Check (1-day Accrual):
The 1-day accrual eligibility rule checks if the submitted absence falls within the AMJO month and verifies that the absence is approved. Only if there is no existing entry in the lookup table for AMJO for the specific eligible year, the integration center program is activated. This program generates a new entry with relevant details, including the eligibility flag as AMJO and the accrual amount as 1.
- Accrual Eligibility Check (2-day Accrual):
Like the 1-day accrual eligibility rule, the rule for the 2-day accrual checks if the submitted absence is during the JFMND months and confirms whether the absence is approved. If there is no existing entry in the lookup table for JFMND for the specific eligible year, the integration center program is activated. The program generates a new entry with relevant details, including the eligibility flag as JFMND and the accrual amount as 2.
- Automatic Entry Generation:
With the above configurations in place, when a user submits an absence of 5 or more days during the specific months, the corresponding integration program is triggered. This program creates an entry for the user in the lookup table, capturing the respective year (Accrual Eligible Year) and the appropriate flag (JFMND or AMJO). This mechanism ensures that only the initial 5+ day leaves for JFMND and AMJO months are considered for accrual calculation.
- Accrual Calculation:
As the time account "Bank of Holidays" runs on a daily accrual basis, we have set up an accrual rule to calculate the accrual amount using the data from the lookup table. The screenshots provided offer an overview of how the accrual is fetched and capped under 3 days for each user.
By implementing this solution, we efficiently manage accruals for the "Bank of Holidays" time account, considering specific conditions and intelligent services to handle different accrual amounts based on eligibility criteria and months of absence.
Conclusion:
The devised solution offers a workaround that has the potential to benefit the community in addressing the complex requirements. This solution optimizes time account accruals for unique requirements by leveraging intelligent services and integration programs. This approach demonstrates the power of ISC and Integration center in solving complex challenges and can be adapted to various industries and businesses with similar requirements.
I would greatly appreciate your feedback on the above solution. Please share any insights or potential loopholes you may have identified to help us improve and refine the approach.
Thank you!
Jaideep Shetty