Skip to Content

/wp-content/uploads/2016/08/back2_1009584.png

Overview

This blog gives you an overview and explains the frequently asked questions on the replication of Employee master data from an external system to SAP Hybris Cloud for Customer. The external system may be SAP ERP, SAP CRM or SAP SuccessFactors Employee Central (EC). Also, the replication is unidirectional from the external system into SAP Hybris Cloud for Customer (Cloud). Employee replication is mediated from SAP CRM/SAP ERP to Cloud through SAP HCI/PI system, whereas the EC integration is a point-to-point integration.


EMP_RLP.png

Once you scope and configure for Employee replication in SAP Hybris Cloud for Customer, a background job is scheduled by default to run every day. This job reads the employee replication requests received in the staging area and creates employees in SAP Hybris Cloud for Customer.

It is important that a SAP Hybris Cloud for Customer administrator looks into the failed requests in Employee Staging, and either corrects the issue or marks the request as irrelevant.

Best Practices

To avoid any errors, follow these best practices:

  • Replicate organization center data from SAP ERP/CRM and only then replicate employees. Otherwise, employee replication will fail due to missing organizations.
  • Use employee replication interface to replicate employees, instead of business partner replication interface.
  • To minimize replication errors, employees from Employee Central should be sent to SAP Hybris Cloud for Customer through an initial load. This creates an organization center hierarchy in SAP Hybris Cloud for Customer, minimizing replication errors.

Frequently Asked Questions

Is it possible to replicate business partners with employee role, if the BP has already been replicated with some other role?

If a Business Partner (BP) is replicated as contact/customer to SAP Hybris Cloud for Customer, it is not possible again to replicate the same BP as employee.

Error: A FATAL EXCEPTION is raised for instance sharing scenario.

What is the significance of Employee Type in replication? Give an example use case where employee replication is affected due to Employee Type Validity?

Employee Type data contains information on the duration of employee’s validity in the system. Say an employee is terminated in CRM/ERP, and Employee Type Validity end date will have termination date of an employee. If employee is sent to Cloud for Customer, whose validity date extends beyond the termination date, then the employee is set to inactive and his user is locked in Cloud for Customer.

Most common use case where employee replication fails is because organization assignment validity is extended beyond employee type validity.

Error Text: “Assigned employee <EMP_NAME> is not valid from <DATE> to <DATE>”.

Can we use business partner service interface to replicate employees from CRM to Cloud for Customer?

BP service interface should not be used to replicate employees. Instead, use Employee replication service to replicate employees from ERP/CRM.

How to manage employee replication background job?

Background job is scheduled only when employee replication is scoped. By default, it is scheduled to run once a day, but a key user can re-schedule the job as required. It is recommended not to configure it to run on “Single Run” or “Start Immediately” option. By doing so, the background job schedule instance moves to “Completed” status and re-run will not be possible. In such a case, an incident is required to create Background job schedule from backend.

What are the steps to migrate employees using migration template?

Follow these steps to replicate employees using a migration template:

  • Navigate to Data Integration  Complete Employee Master Data Replication work center view.
  • To launch Migration workbench, click Actions  Upload Complete Data.
  • Download migration template from the launched view.
  • Follow these guidelines while filling the template:
    • On the Grouping tab, make an entry in key column “File Creation Date Time” in the format “YYYY-MM-DD hh:mm:ss”.
    • On the other tabs, maintain the same value for “File Creation Date Time”.
    • In the “Person ID Type” column, enter the value “1” for ERP remote employee ID, or “2” for CRM business partner remote ID.
  • Upload the filled template using migration workbench.
  • After the data is successfully uploaded, navigate to Data Integration  Complete Employee Master Data Replication work center view.
  • Verify the data is loaded into staging.

Can we replicate private address of an employee to C4C?

Employee view in Cloud for Customer shows work place address and not private address. Hence, private address is not replicated.

How is ID mapping used in employee replication?

On replication, Cloud for Customer maintains a mapping between employee IDs in the external system and the Cloud for Customer system.

When an employee is replicated, the replication service checks the existence of external ID in this ID mapping. If external ID is not found,

it creates a new employee in Cloud for Customer, else if it finds the mapping, it updates existing employee data.

Is it possible to send an employee without organization assignments? What are the common failure use cases around org-assignments to employee?

Yes, it is possible to replicate an employee without org-assignment.

Most common issues around org-assignments to employee are that the replication fails if:

  • An employee assigned to an organizational unit is not replicated to Cloud for Customer.

       Error Text: “Remote org unit <REMOTE_ORG_ID> with definition Functional Unit from <REMOTE_SYSTEM> not yet replicated”.

  • An org-assignment validity extends beyond employee validity.

       Error Text: “Assigned employee <EMP_NAME> is not valid from <DATE> to <DATE>”.

What is complete transmission date in the context of employee replication? And what are unchanged indicator and how do they influence employee replication?

Complete Transmission Start Date (CTSD) is the date from which complete data of an employee is transmitted.

For example, if CTSD is 01.01.2013, then all data of an employee from this date, say Personal Details, Org-assignment, and Workplace Address are transmitted to Cloud for Customer.

Unchanged indicator is provided to restrict modification of data in Cloud for Customer. It is always set to false during initial replication of an employee. Following unchanged indicators can be set on the employee replication request:

  • PersonalDetailsUnchangedIndicator: If true, update to Personal details data of employees is restricted.
  • WorkplaceAddressUnchangedIndicator: If true, update to Workplace details data of employees is restricted.
  • OrganisationalAssignmentUnchangedIndicator: If true, update to Organizational assignment data of employees is restricted.
  • EmployeeTypeUnchangedIndicator: If true, update to Employee Type data of employees is restricted.
  • IdentityUnchangedIndicator: If true, update to Identity data of employees is restricted.

Which attributes are mandatory for employee replication?

Following attributes are mandatory to successfully replicate employees to Cloud for Customer.

  • Business System ID

        Error Text: “Remote system instance ID missing”

  • Remote Employee ID/Business Partner Remote ID

        Error Text: “Remote employee ID or Remote business partner ID missing”.

  • Last Name of an Employee

        Error Text: “Last Name mandatory. Enter last name”.

  • Employee Type data

        Error Text: “Employee type missing for remote employee <REMOTE_ID> from <REMOTE_SYSTEM>”.

What are the effects of changing business system after the initial load of employees to Cloud for Customer?

When employees are replicated from an external system, ID mappings (Remote ID – Local ID) are maintained in Cloud for Customer, with respect to a business system from where an employee is replicated. If the business system changes after the initial load, all employees are again created in Cloud for Customer.

In case if such a situation arises where a business system has to be changed after initial load, then first update the business system in ID mapping for all the employees. This could be done either by Data Workbench or ID mapping download/upload utility.

Once the existing ID mappings are updated with new business system, employee will not get duplicated in the Cloud for Customer system.

How are the employees from staging processed? Is it in sequential or parallel processing mode?

Employees from the staging are processed via background job in parallel processing mode. Employees from external system are sent in packets to Cloud for Customer employee staging. The processing of employee replication request also happens in packets, and in a packet if one replication fails the entire packet will fail to replicate in parallel processing mode. Packet with failed replication request will be processed in sequential mode.

Can an IDOC have multiple instances of the same employee?

An IDOC will not have multiple instances of the same employee.

How to configure Cloud for Customer to integrate with Employee Central.

Please refer the following document on SAP Service Marketplace: INTEGRATION: EC Service Center + Cloud for Customer

• INTEGRATION with Employee Central – Mappings at Field Level

Which attributes of Employee Central are mapped to attributes in Cloud for Customer?

Please refer the following document on SAP Service Marketplace: INTEGRATION with Employee Central – Mappings at Field Level

Is it possible to assign same user ID to different employees in Cloud for Customer?

For every employee replicated, business user is created with a unique user ID. Same user ID cannot be shared or multiple employees cannot have same user ID. It is possible to update the user ID in Cloud for Customer but again it should not be assigned to some other user.

Error Text: “An identity with the same ID <USER_ID> (<Employee Name>) already exists”.

Can we use attribute “ScheduleProcessingDirectlyIndicator” to process employee replication request immediately?

Please do not use this attribute as it is not supported. Instead the workaround is to schedule the employee replication background job to run at shorter intervals of time like every hour or two.

How to ensure that employee replication is working fine?

Key user or administrator needs to regularly monitor the employee replication job and employee staging for the failed jobs or failed replication requests. For every failed request, look at the error and take the necessary action either by correcting the data in the staging or by marking it as irrelevant, if the data is outdated.

Why is Employee staging view failing to load the data?

This issue usually occurs if there is any inconsistency in FSI. By FSI reload it should get resolved.

Note

If your issue is still not resolved, then please raise an incident for SAP Support. Also, please send the following information in the incident:

• Problem description

• Steps to reproduce

• Cloud for Customer Message ID

• IDoc number from ERP/CRM.

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

  1. Chandan Bankar

    Hello Raghavendra Jadi ,

    Thanks a lot for the details on Employee replication. Can you also elaborate how to avoid the below issue?

    When employee leaves the organization, employee role is removed in CRM, resulting into a replication towards C4C which fails with error – “User not authorized to delete employee ID”. Expectation is to change the Employee to no longer be used. Can you please elaborate on how to avoid this?

    Regards,

    Chandan

    (0) 
    1. Raghavendra Jadi Post author

      Hello Chandan,

      When an employee is terminated, he is replicated with employee type validity delimited.

      In C4C such employee becomes inactive and the user is locked.

      Can you please open a ticket with detailsteps and scree-shot of error. We would like to look into this issue.

      BR,

      Raghu

      (0) 
        1. Satya Manideep

          Hello Ravi,

          I have replied to the incident. Please avoid using BusinessPartnerReplicationIn service to replicate or modify employees in C4C. You have dedicated services for Employee Replication with better error handling ease of use. Please contact me via incident for any queries.

          Regards,

          Manideep Satya

          (0) 
          1. Chandan Bankar

            Hello Raghavendra Jadi/Satya Manideep,


            Technically, Employees are also Business Partners in CRM, so whenever there is changes done on it, it triggers Business Partner IDOC. This is true even when new employees are created. I am trying to understand how to configure it to trigger via Employee specific IDOC, so that whenever there is any changes/new creation of Employee, it should be triggered via Employee specific IDOC and avoid Business Partner IDOC.

            Maybe I missed this documentation, if it is already mentioned somewhere, can you please help me with this information?

            Regards,

            Chandan

            (0) 
            1. Dedeepya Reddy

              Hi Chandan, The Employee IDOC is triggered from CRM if there are Employees originated from SAP HCM as the target structure mapped for C4C Employees in such case is as well HCM based structure. It is not possible to map CRM Employees (originally created in CRM) to map as Employees in C4C as the structure would predominantly. Incase if you require Employees from CRM to be mapped to C4C Employee BO, you would have to implement a BADI to trigger the COD Employee IDOC and pass the necessary parameters for a successful replication BR Dedeepya

              (0) 
  2. Arian Zand

    Hello,

    I scoped the replication of employees and I also mapped the exisiting employees in C4C with the existing employees in ERP by Integration of ID mapping.

    But I want to avoid that the system creates new ERP employees which are not in C4C

    Can I manage this ?

    (0) 
    1. Raghavendra Jadi Post author

      Hello Arian,

      If I understand correctly:

      – Employees are locally created in C4C.

      – Employee replication from ERP is scoped in C4C.

      – via ID mapping, you have mapped C4C employees with external(ERP) employee ID.

      – Employees(which are already in C4C mapped to external ID) when replicated from ERP should not get created again. Is that your question ?

      If yes, they will not get created rather updated provided that source system is same as maintained in ID mapping for these employees.

      BR,

      Raghu

      (0) 
      1. Arian Zand
        • Employees are created in C4C and also in ERP and I have mapped this using integration for ID mapping in C4C
        • Employees replication is scoped in C4C

        My question is, when NEW employees are created in ERP are they also going to be created automatically in C4C? Or are only mapped employees updated ?

        (0) 
        1. Raghavendra Jadi Post author

          Hello Arian,

          If you have set-up the integrtaion between between C4C and ERP and employee replication is scoped, then employees created/updated in ERP will get replicated to C4C.

          BR,

          Raghu

          (0) 
          1. Rajiv Juarbal

            Hi Raghavendra,

             

            What if you have an employee already replicated in C4C from source A (it already has a ID mapping entry in C4C) then same employee (same external ID) but from differenct source (let’s say source B), will it create a new employee in C4C or it will just update the existing one and create an ID mapping entry with different source system?

             

            Regards,

             

            Rajiv

            (0) 
  3. Brioni Davide

    HI Jade,

    thanks for this blog.

    I have two questions:

    1) Isn’t possible to set up C4C to store employees metadata in SAP Cloud Identity Service?

    2) Do you know if existing C4C APIs for creation, modification, delete.. employees metadata with synchronous call for not a massive synchronization?

    BR and Thanks

    Davide

    (0) 
  4. Nikhil Pais

    Hello Raghavendra,

    We have integrated our SAP C4C solution with SAP ERP using SAP HCI as our middleware. When we try replicating Employees from SAP ERP to C4C, the Employees flow into the Data Migration WC. The issue we are facing is that the Org assignment doesn’t flow with the  Employee data. We have already prior to replicating Employees, already replicated the complete Org Structure from SAP ERP to SAP C4C.

    Any suggestions pointers on this will be very helpful.

    Thanks and regards,

    Nikhil

    (0) 
  5. Mark D. Huelsman

    We have integrated our Employee’s and Org Structure. That works but it does not allow us to use the secondary or non primary org assignments in C4C.  When we syncs  the employee’s it pulls them from the secondary Org unit and only puts them in their primary. We were hoping and thinking that the system would leave the secondary assignments alone and not update them. We were not so lucky. This works well for us as we have set up structure for the “dotted line” reporting that is wide spread in our company.

    Any suggestions?  Does ECC support secondary assignments?

     

    (0) 
    1. Tobias Träger

      Hi Marc,

      so you say the secondary org assignment vanishes on every newly transferred employee update (i.E. mail change, name change etc)? If yes, have you found any solution yet?

       

      We also have Employee integration working but need the secondary org assignments to get our authorisation working as required.

       

      So it would be really bad if the secondary assignments vanish.

       

      Best Regards

      Tobias

      (0) 
  6. Tobias Träger

    Hello,

    is it possible to stop the system from creating business users on employe syncronisation?

    We have a whole bunch of employees we need to integrate for proper working of some partner roles in Accounts and Contacts.

    Unfortuanely the system always creates a business user for those employees too and so fills our business user list with a lot of not needed junk.

     

    Best Regards

    Tobias

    (0) 

Leave a Reply