Skip to end of metadata
Go to start of metadata

Purpose

This article is meant to assist customers in setting up their distribution model for master data distribution from HR to E-Recruiting through ALE message type HRMD_ABA.

Overview

Message type HRMD_ABA allows the distribution of several infotypes from ECC to E-Recruiting standalone. However, it does not make sense to distribute all the infotypes and respective subtypes allowed by HRMD_ABA. When not using a distribution model to filter these infotypes, you might notice that your IDocs will be generated with ALL subtypes of infotype 1001, which is undesirable, as it will not only impact the system performance, it will also overwrite local relationships which were created by the IDoc inbound processing. So using a distribution model for HRMD_ABA is usually mandatory for all environments.

To maintain a distribution model, you can use transaction BD64. On that transaction, if you need to create a distribution model for HRMD_ABA, you can use the template from CRM/SRM as reference to your E-Recruiting distribution model (provided that the RFC connection between your systems is operational, and you have defined the Logical Partners for usage on transaction WE20 and note 615896 is installed. The templates for HRMD_ABA seem to have been delivered with this note):

After creating a distribution model and adapting it to your needs, please remember to distribute it to the other systems:

If you need further information on which infotypes are necessary for master data distribution, please follow through the filter recommendations from notes 934372 and
550055. Please note that on E-Recruiting, we also send the relationship P-209-CP similarly to SRM, as we have support for Concurrent Employment on E-Recruiting.

Common issue: Forgetting to define a distribution model for HRMD_ABA

If you forget to define a distribution model for HRMD_ABA, one issue that commonly occurs is that every time you send an IDoc for an Employee or an Organizational Unit, it will generate a new Business for it. For example, considering that you are sending data for a specific employee with no distribution model set up:

The IDoc generated will contain all infotypes and respective subtypes allowed for message type HRMD_ABA, even if there is no respective record existing on your HR system. Just to remember, this is how the segment structure is generated for IDocs from message type HRMD*:

On a normal situation of distributing an existing infotype record from HR to E-Recruiting, the IDoc will be generated on HR with both segments E1PITYP and E1PNNNN (E1P0000, E1P0001, E1P0002, etc...), and during the inbound processing on E-Recruiting, the system will:

  1. Check data from segment E1PITYP and delete everything locally respective to the period and object stored on the E1PITYP segment.
  2. Replicate the data from E1PNNNN to the local target system, filling the gap created by the E1PITYP segment (that's why it's important to maintain the coherence between the data on E1PITYP and E1PNNNN segments, in case you are creating your own implementation on the outbound processing in the HR system).

However, on situations where there is no infotype record on your HR system, either because there was none in the first place or because the record was just deleted, the IDoc generated will have only segment E1PITYP without segment E1PNNNN for that infotype, in order to signal this occurrence to E-Recruiting and delete data locally there. After the E1PITYP segment is used to delete data, no data will be replaced there as there is no E1PNNNN segment.

So, upon arriving on the E-Recruiting system, the P data is converted to CP data, and, supposing this is a initial distribution, the inbound processing will create the BP for the CP as the CP doesn't have one BP linked to it yet:

Please note that the link between CP and BP is created as a record on infotype 1001 subtype B207 for the CP object.

Then, if you proceed to distribute data again for this same employee, you will once again send all the possible infotypes and subtypes, INCLUDING infotype 1001 subtype B207 which object P usually doesn't have on a HR system. So the IDoc will be generated with an E1PITYP segment without E1P1001 segment for infotype 1001 subtype B207:

Upon arrival on E-Recruiting, all data from object P is translated to object CP. When infotype 1001 subtype B207 is processed, it will cause the deletion of the previous existing infotype 1001 subtype B207 for the CP on E-Recruiting, cutting the link between CP and BP:

And as the CP has now no BP, the inbound processing will create a new BP for the CP:

When facing such inconsistency, first create your distribution model filters for HRMD_ABA to ensure this won't happen again. Then you can resort to the reports available on note 996789. The reports available there are able to restore the link between a CP and a BP belonging to the same person by specifically checking if the name is the same (they will not work otherwise). Then, you can delete the duplicate BPs with transaction BUPA_DEL.

Related Content

Related Documentation

Documentation on ERP Integration (for EhP5).

Related Notes

SAP Note 996789: Business partner integration: Collection of help reports
SAP Note 934372: SRM/CRM: HR integration for business partner - New features
SAP Note 615896: HR-ALX: Distribution models - Templates
SAP Note 550055: EBP/CRM: New integration for business partner
SAP Note 312090: Integration HR - EBP/CRM