Blog Written By: Cole Fennel, www.colefennel.com
If you have worked in the Higher Education or Medical industry you have likely come across a very common requirement…. Concurrent Employment.
For those not familiar with Concurrent Employment, imagine a large university in America and the jobs available there. It is not uncommon for one student to work part time at a dining hall, part time as a Resident Advisor at his or her dorm, and part time as a research assistant. Aside from students, the University may also have faculty members who work as a tenured professor for one department, and a researcher on a federal grant in a different department. Since these scenarios involve multiple unique responsibilities, and often stretch across organizational structures, it can be difficult to represent these employees using only one employment.
That is where Concurrent Employment comes in. Concurrent Employment in Employee Central allows one person to have multiple employments at the same time. They can still login using one username and have access to all of their personal data on multiple assignments.
As someone who has implemented Concurrent Employment in Employee Central and Employee Central Payroll, I want to provide some tips and lessons learned based on my experiences.
1. Only implement Concurrent Employment if you need it
Concurrent Employment adds considerable complexity to the HCM environment, especially when you consider the integration to external systems which may or may not support it. If Concurrent Employment is enabled, every interface then needs to take into account that an employee may have more than one active position. Some pre-packaged CPI flows to third party systems say outright that they do not support Concurrent Employment, in which case you then have to build a custom flow, or find a workaround, for what would have been an out-of-the-box integration.
If your organization only has a handful of employees who would take advantage of the Concurrent Employment functionality, I would not recommend implementing it. The added complexity would make the added convenience for those employees not worth the effort. Concurrent Employment should only be considered if a person having multiple positions is truly at the core of your organization. Like I said, this is most common in complex University or Medical environments.
I’m not writing this to dissuade you, just to say that for most organizations this feature is simply not needed. It should be reserved for highly complex organizations and a full cost / benefit analysis should be conducted first to see if it is a feature you want to take advantage of.
2. Personal information will be “shared” by each employment
When Concurrent Employment is enabled, it enables one person to have multiple employments. This enables them to have multiple Employment Information entities, each with a corresponding Job Information, Compensation Information (recurring and non-recurring), and Payment Information for each.
In a Concurrent Employment scenario, the person still only has one Biographical Information and all connected entities. This means they only have one Address Information, Personal Information, Contact Information, National ID, and Emergency Contacts / Dependents. From an SAP on-premise point of view you could say these entities are “shared” by each assignment, though it is probably more accurate to just consider these entities as belonging to a person, rather than belonging to an employment.
I put together the below diagram to show a breakdown of a person with two employments. All the entities tied to the employment object will be unique to each employment as shown.
One limitation of Concurrent Employment currently is that the MDF based Payment Information portlet is stored on the user and not on the person, so it is not shared by all employments. That means the employee would have to maintain bank information separately on each assignment. In my experience, we by-passed storing the Bank Information in Employee Central altogether because of this limitation, and instead stored it in Employee Central Payroll.
3. Know your identifiers: User ID, Username, Person ID and possibly… Assignment ID
Deciphering the various identifiers for a person in Employee Central can be startling at first. Here are how the identifiers work when Concurrent Employment is in play:
- Person ID / Person ID External – This is the unique identifier for the person in Employee Central. No matter how many assignments a person has, they will only have one Person ID. This can typically be found in Employee Central’s Biographical Info.
- User ID – This is the unique identifier for the employment in Employee Central. If an employee has multiple employments, they will have a separate user ID for each assignment. This is stored on the User object.
- Username – This is what the user uses to sign in. In Concurrent Employment situations, Employee Central will still generate a new username for each assignment. Typically the employee only uses one of the usernames to login and the others are treated as “dummy” usernames and are never used to sign in. When an employee logs in using their active username, they are able to navigate to all of their assignments without having to log out. The Username is stored on the User object.
I also mentioned Assignment ID because in Q3 2019 SAP will be adding a new unique identifier called Assignment ID to Employee Central. From my current understanding the new Assignment ID will be an additional identifier on the Employment object, similar to User ID. I’ll likely update this blog when more information is released.
4. Main Assignment is determined by an MDF object called SecondaryAssignment
In SAP HCM systems there is a very important idea of the “main assignment” when using Concurrent Employment. This main assignment is typically the primary assignment for an employee and sometimes holds the tax and benefits infotypes. Typically Infotype 712 holds the main assignment information in SAP HCM.
In Employee Central the idea of a main assignment exists also. When an assignment is selected as the main assignment, it will have a yellow star next to it as shown below.
The main assignment can be changed by making an edit to the Employment Info / Employment Details portlet. When Concurrent Employment is enabled, there is a special field that represents whether the employment is the main or not. You can see that in the screenshot below:
On the back end, whether the assignment is primary or secondary is stored in an MDF Object called Secondary Assignments. When a secondary assignment is made the primary in Employment Details, or by terminating the primary assignment, the SecondaryAssignment MDF Object is automatically updated in the background.
Typically the SecondaryAssignment MDF object never needs to be manually adjusted since changes to it can be made directly in Employment Info / Employment Details. However, it can be viewed and edited using Manage Data. The key identifier is the person-id-external. Under Secondary Employments for all SuccessFactors Processes, it should list every assignment which is tied to the person except for the primary assignment. This may seem backwards, listing all the secondary assignments rather than just the primary one, but that is the way it is stored.
The great part about this is that the SecondaryAssignments object is an MDF object, meaning it can be queried via OData APIs. In addition, the Compound Employee SFAPI has special flags that specify whether or not an employment is primary, which brings me to tip #5.
5. With some custom code, this main assignment can be replicated to Infotype 712 in ECP or SAP HCM
In my most recent implementation using Concurrent Employment, it was critical that we kept the main assignment in sync between Employee Central and Employee Central Payroll. Unfortunately, PTP replication (and also BIB replication) does not support keeping Infotype 712 in sync using only configuration. Luckily it does provide plenty of BADIs where customizations can be made.
If the SecondaryAssignments segment is requested, the SFAPI Compound Employee API sends a SecondaryAssignmentPeriod for every employment that is listed as a secondary assignment. Using that, I was able to tell which assignment was the main and write custom ABAP code to keep Infotype 712 in sync during PTP replication.
Here is what Infotype 712 looks like, for reference. The checkmark is on the main assignment.
Rather than using the SFAPI, a custom interface could be created to call the OData API SecondaryAssignments object directly. But since PTP was already using the SFAPI, I decided to go that route.
Follow up and Additional Resources
I hope these tips give you a little bit of clarity on the intricacies of Concurrent Employment in Employee Central. This blog was not meant to be an implementation guide on how to enable Concurrent Employment, for more on that you can check the resources below.
- SAP Implementation Guide on Concurrent Employment
- SAP Notes on Concurrent Employment
- Concurrent Employment FAQ – https://launchpad.support.sap.com/#/notes/2092654
- Another Concurrent Employment FAQ – https://launchpad.support.sap.com/#/notes/2318773
- Using Business Rules with Concurrent Employment – https://launchpad.support.sap.com/#/notes/2541439
- OData and SFAPI use of Concurrent Employment – https://launchpad.support.sap.com/#/notes/2326735
- Other Blogs on Concurrent Employment
- This is an excellent blog on integrating with Employee Central using Concurrent Employment. I did my best not to overlap the content. Great work Biplab Das!