Skip to Content

EC Payroll initially came with a middleware as explained earlier in the Blog Successfactors Employee Central Payroll or On premise Payroll

Now with 1605, Net New customers  no longer need a middleware such as Boomi or HCI to integrate EC with Employee Central Payroll (ECPay)

As explained the architecture for a Typical EC Payroll before release 1605 was as below, Note for EC on Premise Payroll customers the below diagram is still valid.

Pic1.PNG

After 1605 Release, No HCI or BOOMI Skills are required and it eases further in System set up and provisioning

The Architecture looks as below

pic2.PNG

As you can see there is no middleware wherein making the replication faster. Also, with this approach No need to keep track on applying latest Boomi integration pack to get new functionality etc. All other functionality like EC TimeSheet Integration is released on PTP only henceforth from 1605 release.

One more important thing to remember there is no Integration Add on PA SE IN to be installed for this functionality as  point-to-point replication is based on software component EA-HRRXX.

These are the typical configuration needs to be done

  • Setup system connectivity
  • Setup replication configuration
  • Setup employee replication
  • Setup EC Time Off replication
  • Setup EC Timesheet replication

For existing Payroll Customers ie based on middleware replication :

  • Immediate migration is not mandatory
  • Future functionality such as new countries or EC Timesheet integration (1605) will only be available with P2P
  • Customers who want to make use of new functionality have to migrate to P2P
  • A set of tools is provided to automate migration and reduce errors and efforts

For the Migration Steps :

Please refer the SAP NOTE  2321421 – How to migrate from PA_SE_IN to EA-HR/PTP?

pic3.PNG

Refer the Customisation Steps here

SAP Customizing Implementation Guide > Personnel Management >  Integration Settings for SuccessFactors Employee Central Payroll

P.S : For further details please see implementation guide on: http://help.sap.com/hr_ecpayroll

To report this post you need to login first.

22 Comments

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

  1. Utkarsh M parikh

    Hi Sidhharth,

    Few questions on data replication from EC to EC Payroll:

    1. New starter, replicates to payroll. Payroll not yet run for first period. Hire date changed on EC. Again replication is ran, Will this change the hiring action in ECPY?
    2. New starter, replicates to payroll. Payroll run for first period. Hire date changed on EC. Again replication is ran, Will this change the hiring action in ECPY?
    3. Leaver, replicates to payroll. Payroll not yet run for the pay period. Leaving date changed on EC. Again replication is ran, Will this change the leaving action in ECPY?
    4. Leaver, replicates to payroll. Payroll run for the pay period. Leaving date changed on EC. Again replication is ran, Will this change the leaving action in ECPY?

    Regards,

    Utkarsh

    (0) 
    1. Siddharth Rajora Post author

      yes it would be in all cases, Please note EC Payroll or SAP HCM system is in sync or needs to be in sync with Master ie Employee Central which is the system for doing all master data changes and should be replication back to HCM system for running payroll with upto date information

      (0) 
  2. Vamshidhar Naini

    Hi Sidharth,

    I was wondering during the start of the project, do we need conversions to replicate data related to additional/recurring payment (infotype 14/15), Savings plan(167) and Benefits info(171) from EC to ECP or it will be handled by the replication configuration.

    Was looking from the historical data perspective.

    Regards,
    Manu

    (0) 
  3. Siddharth Rajora Post author

    Manu
    Typically after Data Migration ie current data only to SFSF, all historical data is delimited in HCM.
    We try to transfer which data is necessary in SFSF. ie important history items and then these are replicated to HCM. SFSF is is your Master system and any changes should be there

    Let me know if you have additional queries on this

    (0) 
  4. Manu Bhutani

    Hi Siddharth,

    I was going through the PTP handbook and it talks about the FTSD(Full trnasmission start date). I understand that this is configured in the middleware like HCI but how to go about it for PTP.

     

    Regards,

     

    (0) 
  5. Siddharth Rajora Post author

    You set in table T77SFEC_PTP_CONF

    also, you decide also when you split or delimit the infotypes during data migration and that is being used also your FTSD.

    (0) 
    1. Manu Bhutani

      Thx for the response Siddharth. We have just started with the implementation.

      1. Is the logic of FTSD is same for EC->ERP and EC->ECP i.e. records valid on or after FTSD are replicated?
      2. I understand that no changes should be made in ED where effective date is before FTSD, in case it is done(with end date 12/31/9999, shouldn’t this be sent to ERP?
      3. Is it necessary to split records in ERP on go-live date, can’t we by-pass this so that only changes move from the first run
      4. If we can’t by-pass then won’t the first run overwrite the record in ERP with same details. for ex go-live date is 01/01/2018, after executing conversion action top of record in erp will be 01/01/2018 – 12/31/9999, same will be the case in EC. if we go by definition of ftsd top of stack record from EC will be replicated which is not required.
      5. Does the middleware start sending changes automatically after first run i.e. last_change_timestamp will be populated in middleware or we need to configure something.
      (0) 
  6. Siddharth Rajora Post author

    Thx for the response Siddharth. We have just started with the implementation.

    1. Is the logic of FTSD is same for EC->ERP and EC->ECP i.e. records valid on or after FTSD are replicated?

    Yes orrect

    1. I understand that no changes should be made in ED where effective date is before FTSD, in case it is done(with end date 12/31/9999, shouldn’t this be sent to ERP?

    data wont be sent if the date is prior to FTSD, ie start date

    1. Is it necessary to split records in ERP on go-live date, can’t we by-pass this so that only changes move from the first run

    It depends upon the requirement, if you take all data from ERP to EC, if only subset of data is sent then splitting is required then top of stack etc, its there is guide

    1. If we can’t by-pass then won’t the first run overwrite the record in ERP with same details. for ex go-live date is 01/01/2018, after executing conversion action top of record in erp will be 01/01/2018 – 12/31/9999, same will be the case in EC. if we go by definition of ftsd top of stack record from EC will be replicated which is not required.

    no it wont overwrite as we do different action reason and we delimit the records in SAP and start a new hiring action and date from data replicated from EC to erp

    1. Does the middleware start sending changes automatically after first run i.e. last_change_timestamp will be populated in middleware or we need to configure something. Yes that’s correct

     

    (0) 
    1. Manu Bhutani

      Thx Siddharth,

      my 4th ques was related to replication from EC->ERP (on premise which will not be system of record from go-live but integrations will continue) . Wouldn’t it overwrite conversion(split) record in ERP going by the definition of ftsd (record valid on FTSD and begin date >= FTSD), plz have a look on the dates i gave….or is there something in middleware by which we can start sending delta from the very first run

      I believe you answered considering EC->ECP replication where FTSD will be one day before the go-live date to bring the hiring record from EC to ECP (Not bringing history in EC but loading hire record on go-live date – 1 and latest record on go-live date)

       

      (0) 
  7. Siddharth Rajora Post author

    even in On premise its the same approach it wont overwrite as you are splitting the data and only transferring current record from the Go live date

     

    (0) 
  8. Siddharth Rajora Post author

    that data wont be in HCM it should be a new record in EC with Go live date! and then transfer it using different event reason to avoid overwrite, this is how it is done. In the guide it explains like this and step by step, i do understand your question,

    Split of the records of all PA infotypes (employee master data) in the SAP ERP HCM system that are within the migration scope is required.
    All relevant infotype records need to be split in a way that the old record ends on the day before the cutoff date and a new record starts on the cutoff date.

    (0) 
  9. Bhaskar Tripathi

    Hi Siddharth,

    Good to see your post.

    My question is more generic related to integration. The impression that is given to me by some “integration” folks is that PTP integrations are not preferred and we should use middleware. Core integration is not my expert area so I don’t argue. But whats your thought on this? I can understand that in EC payroll case it makes sense to have PTP as SAP wants to make the new HR solution seamless, but what about in general?

    Cheers!

    Bhaskar

     

    (0) 
  10. Siddharth Rajora Post author

    if you are using ECP, We only offer P2P, there is no other way ie no integration for master data it should be p2p

    But if you have ERP or own HR On premise system you have to use integration based on HCI (recommended) , we have to use integration here and cant use P2P, P2P is only for ECP

    (0) 
  11. Manu Bhutani

    Hi Siddharth,

    In table T77SFEC_CVMAPC we can do one to one mapping of event reasons but standard action reason code is same for a couple of actions, ex action reason 01 is there for HIRE as well as for Org reassignment in ECP. How can we map event reasons for this ex.

    Do we need to create custom action/action and action reasons reasons in ECP so that one to one mapping can be done or SAP takes care by taking into consideration how events are mapped.

    Regards,

    Manu

    (0) 
  12. Siddharth Rajora Post author

    In EC we deliver standard ones and yes in ECC HCM you can interpret them as differently

    also

    Per default following events are mapped to a personnel action massn
    as defined by table T77SFEC_CVMAPS:
    event     massn
    26        10
    3         10
    EGA       10
    GA        01
    H         01
    R         12

    Here the main events are
    26 = termination
    H  = hire
    R  = rehire
    GA = start of global assignment
    EGA = end of global assignment

    .
    You can overrule the default settings as described in the implementation guide.

    Per default delivery each employee central event reason is mapped to a space value for the
    personnel action reason massg.

    Events or event reasons which are not mapped are filtered out.

    (0) 

Leave a Reply