SAP Knowledge Base Article

2717481 - Setting up the INITIAL Employee to BP synchronization in S/4HANA

OnPremise
Component: CA-HR-S4-OP-BP (HCM Business Partner Integration), Version: 7, Released On: 04.07.2023

Symptom
There are some important points for customers to consider when setting up the initial Employee to Business Partner
synchronization after a successful CVI conversion. Please proceed to Resolution section below for detailed explanation for
each of the covered points. This will help during the initial planning and evaluation in the use of this functionality.
Recommended approach for initial synchronization.
Handling Active/Inactive status of the employees in the synchronization.
Cleaning up unexpected pending sync entries from table /SHCM/D_BP_SYNC.

Environment
Employee to Business Partner synchronization in S/4HANA OnPremise

Resolution
Recommended approach for initial synchronization

The recommendation is to always use /SHCM/RH_SYNC_BUPA_EMPL_SINGLE report for the initial synchronization.

Huge amount of data may need to be processed during the initial synchronization, that is why the SINGLE report is much
more optimal for this task. Also, this report has a selection screen based on PNP logical database which allows more refined
selection criteria and a parallelization parameter which allows to provide a range of PERNRs (usually around 500 employees
is a suitable value). With this, you can schedule the report in multiple background jobs of 500 employee's each, based on
number of background/update processes available. By having this parallel run, the performance can be greatly increased.
Always try to trigger this synchronization in business downtime hours.

So a suitable approach for the initial synchronization would be as follows:

1. If delta report /SHCM/RH_SYNC_BUPA_FROM_EMPL is active and scheduled in SJOBREPO transaction, then it
would need to be temporarily switched off until the initial sync phase is fully completed (the delta report will be
delivered inactive by default in SJOBREPO for future releases).

2. Additionally while the initial synchronization is taking place, it will be useful to temporarily set up the highest date
31.12.9999 in T77ZZ view (maintenance from SE16 allowed, REPID = /SHCM/RH_SYNC_BUPA_FROM_EMPL ,
OBJECT = CHANGED). Doing this any undesired data manipulation coming from an accidental online run of delta
report can be prevented at this time.

3. Then SINGLE report can be executed based on the requirements in order to synchronize the target employees, either
with or without parallelization, etc. Please refer also to next section describing active/inactive status considerations. Also
for more details about parallelization, please follow the recommendations in FAQ note for 2409229 regarding process
the employees in parallel jobs.

4. Only after all the relevant target employees have been synchronized successfully, ensuring there are not any pending
errors, then current date could be set up manually in T77ZZ table as the last successful synchronization date
(maintenance from SE16 allowed, REPID = /SHCM/RH_SYNC_BUPA_FROM_EMPL , OBJECT = CHANGED) and
then the delta report /SHCM/RH_SYNC_BUPA_FROM_EMPL could be scheduled daily from next day onwards (either
reactivating again in SJOBREPO or defining the job in SM36).
Remark: do not start the delta daily sync job nor change T77ZZ table yet if there are many records pending to be
processed or not completely processed yet. When daily job is first started there should not be failed records, so that the
delta synchronization will work correctly and as expected.
 5. We recommend you to run the report /SHCM/RH_SYNC_BUPA_FROM_EMPL without using the RFC
connection parallel mode as a batch job. The report should only detect the changed employees that were changed since
the last time the report was run. Normally the report runs as regular period like everyday, therefore no many employees
will be processed and there is no need for parellization. When running the report like this, entry T77ZZ will be updated
every day, once the job was completed without relevant synchronization dump or errors.

In case, you are using Inbound Destination with a RFC connection in batch job fro delta
report /SHCM/RH_SYNC_BUPA_FROM_EMPL, the report then is creating several bunches of employees that are
being executed in parallel processes with the RFC connection. Many processes will be run. Since the delta program
/SHCM/RH_SYNC_BUPA_FROM_EMPL cannot know whether all the processes did run fine, the entry in T77ZZ will
not be updated.

Handling Active/Inactive status of the employees in the synchronization

During the initial setup of the S/4HANA Employee to BP synchronization, customers should plan and decide how they will
need to handle inactive employees in the system (this would be especially relevant for customers who are migrating from an
SAP ERP system with some recently terminated employees or some nearly upcoming terminations).

For some customers, inactive employees from the past may have obsolete or no longer valid data which would raise some
errors during BP synchronization, getting these employees added to delta log table /SHCM/D_BP_SYNC, etc. requiring some
adjustments on the data. So, in general, it is open for customers to decide whether they need to synchronize also the inactive
employees or not. But please note that in case of any pending settlements or any subsequent activities needed for these
inactive employees, then the recommendation from standard perspective would be to synchronize this data and not skip it.

It is also important to remark that the SINGLE report /SHCM/RH_SYNC_BUPA_EMPL_SINGLE is based on PNP logical
database and therefore allows to selectively EXCLUDE inactive employees via selection screen filtering. On the other hand, it
is not expected to have any filtering criteria in the delta report /SHCM/RH_SYNC_BUPA_FROM_EMPL to filter based on
the status, as this report will exclusively rely on the delta mechanism. This logic will pick up data as follows:
• Data sets with end date of validity period = yesterday
• Data sets with begin date of validity period = today
• Individual employees pending from a previous unsuccessful synchronization (employees in /SHCM/D_BP_SYNC delta
log table)
• Employees with changed relevant infotype records, based on AEDTM modification date happening after cutoff date in
T77ZZ

So for example some customers may decide to do the initial synchronization (therefore SINGLE report) first only for active
employees and then in a later run include the inactive ones if needed, etc. In such case they would need to consider adjusting
T77ZZ and/or table /SHCM/D_BP_SYNC when starting such second phase (proceed to next section for further information
about adjustment on this table). Alternatively, other customers may decide to synchronize all active and inactive employees at
once during initial sync.

Some possible scenarios for customers to evaluate regarding the active/inactive status would include:
A. Employees who were already inactive in S/4HANA before the initial BP synchronization is even started.
These ideally would not be picked up by delta synchronization job (because of updated T77ZZ date was updated after
initial successful sync)

B. Employees who will be terminated while the initial synchronization is being setup.
These could be handled differently by customers, depending on their requirements. They could perhaps terminate these
already in S/4HANA system only (even with a past date) so pending settlements or subsequent activities are possible
with the corresponding vendor, etc. Alternatively, they may decide to terminate them already in SAP ERP but then
pending settlements or subsequent activities may no longer be possible in S/4HANA.

C. Employees who will be terminated after completing the migration and initial synchronization.
These will be picked up once by Delta job (because of delta changes and T77ZZ), and BP role will be adjusted accordingly
(or added to the delta log table in case of errors).

D. Already inactive employees from the past, for whom some relevant infotype data is changed nowadays.
These will be picked up by the delta sync job and synchronization will be triggered (or added to the delta log table in case
of errors).
Note: There is standard logic change about T77ZZ, after apply note 3164012 - Improve daily EMPL sync data
selection.

After applied the note correction, Table T77ZZ is no longer used to update the lastest change date. Instead T77ZZ, now
table /shcm/d_sync_run is used to record the last execution date, and this table is properly updated in your system. Please
also refer to consulting guide KBA 3351242 - T77ZZ entry will be refreshed into blank after delta report
/SHCM/RH_SYNC_BUPA_FROM_EMPL execution

Cleaning up unexpected pending sync entries from table /SHCM/D_BP_SYNC

Under some scenarios, customers may end up with huge amount of entries which may not represent the exact target
population of employees which is subject to be controlled and synchronized. A sample report ZRH_SYNC_LOG_UTILITY is
provided in attachments section to help customers if these types of adjustments are needed.
Note: please note this report is only provided just as an example of such assistance tool which could be used for the table
adjustment, but customers must evaluate this accordingly before using the tool, and they must evaluate if -and which- entries
would have to be adjusted or removed, if any. If valids and expected entries from /SHCM/D_BP_SYNC are removed, this
could cause that pending errors during the synchronization are no longer tracked and therefore new synchronizations may
not trigger again for those pending employees. In worst case scenario, customers may need to force a new full synchronization
for all the target data to ensure mass consistency.

See Also
Please also refer to S/4HANA Installation guide and to the following related KBAs:
2578294 - FAQ - Employee to Business Partner synchronization in S/4HANA OnPremise
2647154 - Performance with Employee to BP synchronization in S/4HANA OnPremise. General troubleshooting guide
3102576 - Why the changed employee master can not be synchronized to BP auto in employee synchronization new
function

Attributes
Key Value

Other Components CA-HR-S4-OP (On-Premise HCM Objects)

This document is referenced by

SAP Note/KBA Title

Attachments
File Name File Size Mime Type

ZRH_SYNC_LOG_UTILITY.txt 1841 text/plain