I am back with a quick treat which might add value to your timesheet implementation project.
Introduction: The customer has implemented Employee Central Timesheet and Time-off with integration to SAP HCM system for both positive and negative time recorders.
Background: When an employee is terminated, the customer wants to close all the time accounts for the employee as of the termination date. This is in the wish-list of many EC Time-off customers. But currently its not available in the product. Additionally, I will also like to inform “It’s not recommended to use a termination rule to close time accounts or set the validity dates of time accounts. This can lead to exceptions in the termination workflow.” This is documented in the implementation guide.
The product management is aware of this requirement and they are working diligently on this which can be tracked in the KBA-https://launchpad.support.sap.com/#/notes/2688247
The recommendation for the time being was Interim Account Update or wait for Period End Process for closure of the time accounts. But as these both approaches were manual, the customer was looking for an automatic process.
So, for the time being, I am taking the opportunity to share a workaround for the automatic closure of the time accounts for all terminated employees.
Workaround: As a workaround, I considered several options like building a custom integration in CPI, IC, Scheduled imports, Offcycle event batch etc. My motivation was to try something the Upsert operation of the Odata Apis. After all we need to do is to do an incremental upsert with the same record and change the “Closed” field value to “Yes” for all the time accounts of the terminated employees. My approach to this requirement is pretty simple:
- Extract the existing time account records of the terminated/inactive employees.
- Change the value of the “Closed” field to “Yes” for the extracted records.
- Incrementally upsert all the changed time account records which should update the existing records and close the time accounts.
So, I thought of trying the Successfactors to Successfactors integration type in Integration Center. As IC is the easiest way to perform Odata api calls in Successfactors without any development tools.
This integration will be scheduled daily with a filter to consider only “Inactive” employees. Whenever it runs, it will extract the existing time account records for the employee. In the integration center field mapping, we will set the default value of the “Closed” field to “Yes”. Then the changed record will be upserted by an odata api call to the “Time Account” entity.
Here are the steps.
Step 1: Launch integration center and create a new Successfactors type integration from “More integration types” options. Make sure you choose the following options.
Step 2: Choose the entity “Time Account (Time Account)”
Step 3: Change the default value of the attribute “Closed” to “True” manually. This is to enforce the time account to be closed.
Step 4: Now switch to field mapping mode and map all the other required fields for the time account entity between source and target. This will ensure that the same records are upserted again.
Step 5: Click next and navigate to Advanced Filters. Choose a filter with the field Status field from the userIdNav sub-entity available in the Time Account entity.
Step 6: Set the filter value to apply for only terminated employees. The value is case sensitive.
Step 7: Add a time-based filter for running this integration to run in delta mode.
Step 8: Save the integration. But don’t schedule it yet. Great, you have created the integration. Now you have to test it.
- Terminate an employee with active time accounts. Please note termination date should not be in the future. The idea is that this integration job will run every day.
- Go back to the integration center and run the integration once.
- Check the time accounts in Manage Data. You should see they are updated as closed for the concerned employees who are inactive.
- On successful testing, you can schedule it to run every day.
This worked for me but I recommend thorough testing of this integration before production deployment. Please comment if you see any issues with this approach.
Thanks and regards,