&DESCRIPTION&.
Scenario 1: Distribution of HR Master Data from a Central Central HRSystem

Precondition
Data is maintained centrally in the integrated HR system. Distributeddata must not be maintained in the target system; see SAP Note 119780.
Message Types

• HRMD_A: Distribution from the HR system to other SAP systems


• HRMD_ABA: Distribution from the HR system to systems that are based on
an SAP application basis system, such as the mySAP.com components CRM,EBP, and so on. For details, see SAP Note 312090.

• HRMD_B: Distribution from the HR system to an SAP basis system. This
message type is not currently relevant, since this system type is notdelivered as a stand-alone product.
Basis IDoc Types
See also table EDIMSG or transaction WE82.
For HRMD_A*, HRMD_ABA*, and HRMD_B*, transaction WE30 displays thecurrent version in each case with the highest sequential number, for theSAP Release 4.70 HRMD_A06, HRMD_ABA04, HRMD_B04.
In normal circumstances, that is when the participating systems are notSAP basis systems, you must use message type HRMD_A or HRMD_ABA. Thesystem suggests the most suitable one on the selection screen in theprogram RHALEINI (or in the transaction PFAL, which has the samefunction).

Output
In accordance with the model views in the distribution model, theselected data is transported to the target system.
Tips and Tricks
For questions and answers on setting up a distribution scenario for HRmaster data, see SAP Note 200066.
Supported HR Object Types
Personnel Administration object types: P Person, AP Applicant (only formessage type HRMD_A)
Personnel Planning object types: all (non-external) object types exceptX*. For information on T*, W*, RY*, see below.
Supported HR Infotypes
Transaction WE30 enables you to display the infotypes currentlysupported by a message type. In this respect, E1Pnnnn means thatinfotype Pnnnn is distributed (assignment in table T777D), and E1PADnnmeans that additional data PADnn for infotype P1001 is distributed(assignment in table T77AD).
For performance reasons you should enter all required object types andinfotypes/subtypes as filters in the distribution model.
Infotypes referring to data that cannot be distributed (such as clusterdata) are not included in the standard system (see SAP Note 105148), orare distributed without the additional information (for example clusterdata, texts) (see also SAP Note 310993).
Customer includes for the infotypes are not automatically taken intoaccount during distribution. Function exits are provided for supportingcustomer includes.
Transfer Mode
The transfer mode determines how data on the objects (= planversion/object type/object ID) is imported into the target system:


• Insert (Create) for Complete Transfer

Data records for all of the objects and infotypes from the distributionmodel are transferred in full to the target system. If an object to betransferred already exists in the target system, it is replaced in full,which means it is first deleted completely (all infotypes) and thencreated again using the distributed data records.
You can specify a reporting period (data selection period). The systemdistributes all of the data records that are valid for at least one daybetween the 'start date' and 'end date'.
For a complete data transfer you must use insert mode. For consistencyreasons we recommend that you use the reporting period 'All'.

• Update (Change) for Period

You can specify a reporting period (data selection period). The systemdistributes the data records of the infotype/subtype to be entered thatare completely within this period. In the target system, data records ofthe entered infotype/subtype that are completely within this period aredeleted (relationships are only deleted if they were created earlier bydistribution, see below: local relationships). The distributed datarecords are then created. In particular, this logic ensures that deleteddata records, too, are correctly processed.
In this mode, IDocs created by change pointer evaluation are dispatched.
Import Lock:
Using an entry in table T77TR in the target system, you can lockspecific object types/infotypes/subtypes for import.
You completely lock object types for import by entering an existenceinfotype:
Lock object type P by entering infotype 0000, object type AP by enteringinfotype 4000, PD object types by entering infotype 1000.
Size of IDoc
Each IDoc transfers a maximum of 200 objects. You can reduce this numberwith an entry in table T77S0: ALE BSIZE.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
Change Pointers
To distribute changes after a complete transport, you can use changepointers. Once they have been activated (in the IMG), change pointerscan be dispatched periodically using report RBDMIDOC.
You can display change pointers
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
and process them again, if necessary.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
Generic Data Filtering
As well as the standard filters, you can define and use generic filters.See the corresponding section in the IMG.
Filter 1 for Distribution of HR Master Data:Execute Function
Filter 2 for Distribution of HR Master Data:Execute Function
To determine the filter values for each HR master data record, you mustimplement a BAdI: DisplayDocumentation
Serialization
For distribution, you can implement serialization. See also the relevantsection in the IMG.
Activate Serialization in ALE Inbound Processing:Execute Function
Activate Serialization in ALE Outbound Processing:Execute Function
Auxiliary programs allow you to control the settings:
You can check the consistency of serialization settings:Execute Function
You can display the counter status of the registry in ALE inbound
processing: Execute Function
You can display the counter status of the registry in ALE outboundprocessing: Execute Function
SAP Enhancements as Function Exits
Under the SAP enhancement RHALE001 are function exits that you can usein ALE inbound and outbound processing.
SAP Enhancements as BAdIs
Business Add-Ins continue to be available in the HRALE00* namespace.
Error Handling
You can use the standard task HRMD_Error (TS 00408178) for errorhandling in ALE inbound processing.
Component for Notes and Error Messages
Notes for ALE distribution of HR master data are stored under thecomponent BC-BMT-OM-ALE. You must also use this component when reportingerror messages in this area.

Restrictions:
HR master data has just one central HR System in which all HR componentsare integrated. Distributed HR master data must not be changed in thereceiving system. Profiles with read authorization only, for example,enable you to ensure that distributed HR master data is not changed inthe receiving system. Alternatively, you can use the original systemmechanism from scenarios 2 and 3.
Only the infotypes required for SAP standard scenarios are supported.
Data in the receiving system is created with the same plan version as inthe sending system. If the active plan version is not selected in thesending system, the distribution program displays an error message.
Only the object type, infotype, subtype, or related object type can beused as a filter. This means that data cannot be filtered in accordancewith any other fixed organizational criteria if there is more than onereceiving system. However, you can define customer-specific filters. Formore information, see the "Generic Data Filtering" section above.
If you want to create additional HR master data records directly in thereceiving system (such as a work center in Logistics), you must ensurethat the number range intervals are different from those in the sendingsystem.
Tasks (object types T*, W*) and responsibilities (object type RY) arenot distributed. The relationship (infotype 1001) for these object typescan be distributed. This means, for example, that you cannot distributea standard task, but that you can distribute a relationship for astandard task.
You can reduce the messages. You can also use rules to convert data,with the exception of using a conversion rule to fill fields withinitial values.
If you want to create a relationship to an object in the target system,but the object does not exist (yet) in the target system, a note isincluded in the transport log. In this instance, the IDoc is assignedstatus 52 (posting of application document incomplete) so thatincomplete transports are recognized. If the missing object isdistributed to the target system at a later date, the relationship iscreated automatically in both directions, and is therefore complete. Arelationship to external objects (such as cost centers) is distributedand created in the target system if the external object exists there.For more information on this topic, see SAP Note 443187.
In update mode, a local PD relationship in the target system isretained. This means that a relationship created locally (not bydistribution) in the target system is not deleted in update mode. On thetechnical level, a distributed relationship can be recognized by thefact that the value AL is entered as an ALE marker in the P1001-REASNfield.
PA data and PD data is saved (updated) in the target system withoutchecks (unlike in dialog or batch input). In particular, this means thatupdated data is not validated (time constraint, time delimitation,allowed values). What is more, no change pointers are written, thetransport connection and workflow connection are deactivated, dynamicactions are not performed. You must take this into account whentransferring data from an interface to an external system. The externalsystem itself must itself ensure consistency and the correct format. Formore information, see SAP Note 134085.
If you want to use standard transactions in the target system to accessHR data, Customizing in the target system must be identical to theCustomizing in the sending system.
Lock in ALE outbound processing: in the sending system, a lock entry iscreated for each object when data is sent. If objects are already lockedin the sending system (by a maintenance transaction, for example), theyare not dispatched. This is documented in the program log. You mustrepeat the send procedure later.
Lock in ALE inbound processing: in the receiving system, a lock entry iscreated for each object when data is received. If objects are alreadylocked in the receiving system, they are not updated. This is documentedin the status of the posted IDoc. You must repeat the posting procedurelater.
When PA infotypes are distributed, you must ensure that at least theexistence infotypes 0000, 0001, 0002, and 0003 for persons, or 0001,0002, and 4000 for applicants, are distributed. For the distribution ofholder relationships (S-P), you must also distribute infotype 1001 forpersons.
In the sending system, you must have authorization (PLOGI, P_ORIGIN,P_APPL, structural authorization for T77PR and T77UA) to display theinfotypes. For holder relationships (S-P), you must have authorizationto display person infotypes (P_ORIGIN) in the receiver system.
Infotype 0003 is only distributed by change pointers if it has beenchanged in combination with one of the other PA infotypes that issupported.

Example
Personnel number for existence check:
Object type: P, infotypes: 0000, 0001, 0002, 0003.
Personnel number for existence check with holder relationship:
Object type: P, infotypes: 0000, 0001, 0002, 0003, 1001.
Applicant number for existence check:
Object type: AP, infotypes: 0001, 0002, 4000.
Personnel number for generating vendor accounts in Accounting:
Object type: P, infotypes: 0000, 0001, 0002, 0003, 0006, 0009, 0017.
Personnel number for sales personnel (maintained in HR):
Object type: P, infotypes: 0000, 0001, 0002, 0003, 0006, 0105, 0900.
Organizational unit, job, position with relationships:
Object type: O, C, S, infotypes: 1000, 1001.

Description
Scenario 2: Distributed Organizational Management
If you require further information on the 'Distributed OrganizationalManagement' scenario, access the SAP Library and chooseCross-Application Components -> Business Framework Architecture ->ALE Business Process Library -> Human Resources -> Master DataDistribution (Human Resources).

Precondition
Scenario 2 'Distributed Organizational Management' is based on Scenario1 'Distribution of HR Planning Data and HR Master Data from a Central HRSystem'.
This scenario is activated in T77S0: ALE REPLI.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
By determining an original system (in original system table HRMDORIGIN),one logical system is determined for each object in Personnel Planning.Business responsibility is defined in this logical system.
A distinction is made between two types of object, namely the original(which usually exists in the system in which the object was created) andthe replication (which is created by distribution).
Initialization
To initialize the original system table, the following function must beexecuted:
Initialization of HRMDORIGIN
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
To maintain HRMDORIGIN in expert mode, the following function must beexecuted:
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
The original can be transferred to a different logical system.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
Objects as Original or Replication
The main differences between the original and the replication lie in thecreation of change pointers and in inbound processing for distribution.
If an object is created in a logical system, that system is regarded asthe original system and the object is stored there as an original. Ifthe object is distributed, it exists in the target system as areplication.
A relationship that is distributed is created in the target system withthe ALE marker (value AL in the P1001-REASN field), which flags it asdistributed.
An original can be maintained. A change pointer is written to distributethe change. In insert or update transfer mode, an original is selectedand dispatched. It is then created in the target system as areplication. This original is not overwritten during inbound processing.
A replication can be maintained. A change pointer is not written todistribute the change because the change is local. In insert or updatetransfer mode, a replication is selected and dispatched if the'Distribute originals only' parameter has not been selected. It is thencreated in the target system as a replication. This replication isoverwritten during inbound processing.
Report RHALEORIGLIST (transaction RE_RHALEORIGLIST) generates a list oforiginal systems for the selected objects.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
Relationships Between Original and/or Replication
A relationship between two originals can be created and maintained.Change pointers are written for distribution. In insert or updatetransfer mode, the relationship is selected and distributed. It is thencreated in the target system as a relationship with ALE marker (seeabove). This relationship between originals is not overwritten duringinbound processing.
A relationship between two replications can be created and maintained.Change pointers are not written for distribution. In insert or updatetransfer mode, the relationship is selected and distributed. It is thencreated in the target system as a relationship with ALE marker. Thisrelationship between replications is not overwritten during inboundprocessing.
A relationship between an original and a replication can be created andmaintained. Change pointers are written for distribution, but only forthe original with a determinable relationship direction. This specifiesjust one system, which prevents data from being distributed from bothsystems in both directions.
The distributable relationship direction is defined in T77ALERELA.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
The distributable relationship direction is assigned in T77ALECOMB tothe object type combinations for original and replication.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
In insert or update transfer mode, the relationship is selected anddistributed. It is then created in the target system as a relationshipwith an ALE marker. This relationship between original and replicationis not overwritten during inbound processing.
A distributed relationship (that is, a relationship with an ALE marker)can be maintained between an original and a replication or between tworeplications. Change pointers are not written for distribution. Ininsert or update transfer mode, the relationship is selected anddistributed. It is then created in the target system as a relationshipwith an ALE marker. This distributed relationship is overwritten duringinbound processing.
If a replication is processed, a dialog box containing the appropriateinformation can be displayed in dialog mode. This function is activatedby an entry in table T77S0: ALE POPUP.
IF &DEVICE&='SCREEN'
Execute Function
ENDIF

Example
There are two systems, A and B, each with activated change pointers anddistribution to the other system using change pointers.
Objects O 4711 and O 4712 have been created in system A and distributedto system B using change pointers, or insert or update transfer mode.
Object O 4713 has been created in system B and distributed to system Ausing change pointers, or insert or update transfer mode.
System A: Object O 4711 exists as an original
System A: Object O 4712 exists as an original
System A: Object O 4713 exists as a replication
System B: Object O 4711 exists as a replication
System B: Object O 4712 exists as a replication
System B: Object O 4713 exists as an original
Processing in System A for Infotypes that are not Relationships
In system A, infotypes 1000, 1002, and so on can be maintained forobject O 4711. The object is an original, so change pointers arewritten.
Distribution by change pointer distributes the changed data from O 4711in system A to system B. System B contains object O 4711 as areplication, so distribution overwrites the data in object O 4711 insystem B.
Processing in System B for Infotypes that are not Relationships
In system B, infotypes 1000, 1002, and so on can be maintained forobject O 4711. The object is a replication, so change pointers are notwritten.
Therefore, distribution by change pointer does not distribute thechanged data from O 4711 in system B to system A. The changes are localand are overwritten again when data from system A is reposted.
T77ALERELA contains the entry 002 A.
T77ALECOMB contains the entry 002 O O.
Therefore, relationship 002 is distributed by change pointers fromobject type O as the original to object type O as the replication withrelationship direction A.
All other relationships between the original and replication, even B002,are not entered, which means they are not distributed by changepointers.
Processing in System A for Relationships
Every relationship between original O 4711 and original O 4712 can bemaintained. Change pointers are written, and the relationship isdistributed to system B.
Every relationship between original O 4711 and replication O 4713 can bemaintained. For relationship 002, a change pointer is written forrelationship direction A002 from original O 4711 to replication O 4713,and the relationship direction is distributed to system B. No changepointers are written for any other relationships. In particular, achange pointer is not written for relationship direction B002 fromreplication O 4713 to original O 4711.
Processing in System B for Relationships
Every relationship between replication O 4711 and replication O 4712 canbe maintained. Change pointers are not written.
Every relationship between original O 4713 and replication O 4711 can bemaintained. Change pointers are not written. In particular, a changepointer is not written for relationship 002 (see above) between originalO 4713 and replication O 4711 because relationship direction B002 hasnot been entered as distributable by change pointer from original O 4713to replication O 4711.

Description
Scenario 3: Distributed HR Master Data
If you require further information on the 'Distributed HR Master Data'scenario, access the SAP Library and choose Cross-ApplicationComponents -> Business Framework Architecture -> ALE Business ProcessLibrary -> Human Resources -> Master Data Distribution (Human Resources)
.
The original system mechanism is retrieved for persons and applicants inthe same way as for scenario 2 'Distributed Organizational Management'.

Precondition
Scenario 3 'Distributed HR Master Data' is based on scenario 2'Distributed Organizational Management' and scenario 1 'Distribution ofHR Planning Data and HR Master Data From a Central HR System'.
This scenario is activated in T77S0: ALE REPPA
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
In ALE inbound processing, PD / PA integration is activated in T77S0:ALE INTE
IF &DEVICE&='SCREEN'
Execute Function
ENDIF
If a replication of a person or applicant is processed, a dialog boxcontaining the appropriate information can be displayed in dialog mode.This function is activated by an entry in table T77S0: ALE POPPA
IF &DEVICE&='SCREEN'
Execute Function
ENDIF