Specifics on P2P that implementations typically miss out!!

[r_gajan]

“The opinions expressed in this is post are that of the author and not endorsed by SAP”

I have been working with some strategic large, medium & small size customers in various industries implementing Employee Central Payroll. Being part of the Product Management and the Engineering, I have been in the advisory role from the product perspective. In this course, I have identified certain key areas of Point-to-Point integration which most projects missed during the initial stages of the project and later cost time & money to rectify. Through this blog, I am documenting all such key areas that the implementation teams should never miss. Happy reading!!!

Know the specifics!!

Point-to-Point is THE standard integration solution between Employee Central (EC) and Employee Central Payroll (ECP). Below are some salient features,

• Does not use Boomi as a middleware. This is a big advantage for customers as they can avoid a special resource with Boomi skills.


• Without Boomi, setting up the integration is much faster and simpler.


• All the data conversion and data mapping logic between EC data points and ECP data points is managed in ECP configuration tables. All-in-All the maintenance effort with P2P is drastically reduced.


• Scheduled job/s in ECP makes SOAP calls to Compound Employee API in EC. The received XML is processed through internal Web Service. Customers schedule (SM36) the job/s as per their needs.


• Status of the replication per employee is sent back from ECP to EC, for monitoring directly in Admin center via Data Replication Monitor (DRM).


• Through DRM, admins can choose to replicate specific employees on an ad hoc basis.


• Faster replication (~2 times faster than Boomi based). This is specifically important for big customers with large data and who have weekly pay frequencies.


• New integration features are delivered only on P2P.

      

---

P2P is applicable to which customers?

• To all ECP customers.


• It is strongly advised that old ECP customers who have already implemented Boomi based integration, move to P2P at the earliest to reap the benefits of P2P. By the Way, the migration is made easy with the availability of some migration tools and a simple step-by-step guide.


• In 2016, I was personally involved with a large North American customer who moved from their Boomi implementation to P2P and was extremely happy about the change. I am sure there are many customers who have already transformed by now.

---

Important details you must know!!

Employee Number Range

• By Default, the employee number range (NUMKR) is set to internal. It is suggested this is left internal unless there is a strong business case. It is specifically recommended using internal number range if the customer has Inter-Country, Global Assignment, and concurrent Assignment scenarios.


• The person ID in EC is replicated into ECP as PERSON ID (Infotype 0709) in ECP. So, activate concurrent employment switch to be able to view personID on PA30/20 screens.


• Implement BADI if external number range is intended.

Stay tuned for more details in my future blogs!!

Jobs and Positions

• In ECP, PD Infotypes including 1000 and 1001 should not be used. Which means PPOME and other PD transactions should never be used in ECP.


• PA-PD integration should always be switched off.


• Eventually, PD objects (Like Org Units, Positions, Jobs) and the relationships are never replicated into ECP.


• However, some implementations do need Job description and Position description for processes like the Payslip. In such projects positions and Jobs can be replicated into the tables T528B, T513 and Infotype 0001. Refer to the ECP implementation guide for T77S0 switch and how to use the program RP_HRSFEC_JOB_POS_REPL to replicate Jobs and positions into T528B/T528T and T513/T513s.


• TIP: Make sure T528B/T513 has no entry with the “OM” column set to “P”. Only when the PA-PD integration is ON, an entry in T528B/T513 will have “P” set which means the record was pushed in from PD Infotypes.


• Leave the number range for positions and Jobs as internal which is by default. The number range cannot be external.

TIP: EC position/job codes are mapped to ECP Position/Job codes in the table HRSFEC_JOB_POS when the program RP_HRSFEC_JOB_POS_REPL is executed.

Data Maintenance and inconsistency

• All Infotypes that are configured for replication, should never be edited directly in ECP system. All such data should originate only from the EC system which will be the system of records. This is to avoid P2P errors because of data inconsistencies between EC and ECP while replication.

Full Transmission Start Date

• This feature can be used to control the retroactive master data changes from replicating into ECP.

Stay tuned for more details in my future blogs!!

Replication frequency

• While scheduling (SM36) the replication program (HRSFEC_PTP_EE_REPL) make sure the jobs do not overlap each other (ex. if you schedule each country as a variant).

Replication monitoring tools and troubleshooting

• All replication status per employee should be available at the Data Replication monitor. Thus, DRM is THE go-to service for an administrator to monitor data replication.


• Below are some utility tools that the technical team uses as a starting point for troubleshooting. However, they can be handy for a consultant during the P2P setup phase,

1. SFAPI Audit log in EC: Admin Center -> SFAPI Audit Log


2. Web Services utility in ECP: Transaction SRTUTIL


3. Application log in ECP: Transaction SLG1


4. Replication status program in ECP: Program RP_HRSFEC_REPLICATION_STATUS

Stay tuned for more details in my future blogs!!

 

!! Important of All: Always access the latest and greatest implementation guide at help.sap.com.

Let me know if this blog has been useful to you? I will look forward to some discussions to be triggered in the comments section below.