Re: Distributed HR Master Data (transaction PFAL

roger_gomez — Wed, 27 Feb 2008 12:06:08 GMT

Hi Mukesh,

One of best options is using ALE. Read below documentation.

Reward points if helps

Roger

HR: ALE Distribution of HR Master Data

Description.

Scenario 1: Distribution of HR Master Data from a Central Central HR

System

Requirements

Data is maintained centrally in the integrated HR system. Distributed

data must not be maintained in the target system; see SAP Note 119780.

Message Types

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

o 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.

o HRMD_B: Distribution from the HR system to an SAP basis system. This

message type is not currently relevant, since this system type is

not delivered 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 the

current version in each case with the highest sequential number, for the

SAP Release 4.70 HRMD_A06, HRMD_ABA04, HRMD_B04.

In normal circumstances, that is when the participating systems are not

SAP basis systems, you must use message type HRMD_A or HRMD_ABA. The

system suggests the most suitable one on the selection screen in the

program RHALEINI (or in the transaction PFAL, which has the same

function).

Output

In accordance with the model views in the distribution model, the

selected data is transported to the target system.

Tips and Tricks

For questions and answers on setting up a distribution scenario for HR

master data, see SAP Note 200066.

Supported HR Object Types

Personnel Administration object types: P Person, AP Applicant (only for

message type HRMD_A)

Personnel Planning object types: all (non-external) object types except

X. For information on T, W, RY, see below.

Supported HR Infotypes

Transaction WE30 enables you to display the infotypes currently

supported by a message type. In this respect, E1Pnnnn means that

infotype Pnnnn is distributed (assignment in table T777D), and E1PADnn

means that additional data PADnn for infotype P1001 is distributed

(assignment in table T77AD).

For performance reasons you should enter all required object types and

infotypes/subtypes as filters in the distribution model.

Infotypes referring to data that cannot be distributed (such as cluster

data) are not included in the standard system (see SAP Note 105148), or

are distributed without the additional information (for example cluster

data, texts) (see also SAP Note 310993).

Customer includes for the infotypes are not automatically taken into

account during distribution. Function exits are provided for supporting

customer includes.

Transfer Mode

The transfer mode determines how data on the objects (= plan

version/object type/object ID) is imported into the target system:

o Insert (Create) for Complete Transfer

Data records for all of the objects and infotypes from the

distribution model are transferred in full to the target system. If

an object to be transferred already exists in the target system, it

is replaced in full, which means it is first deleted completely (all

infotypes) and then created again using the distributed data

records.

You can specify a reporting period (data selection period). The

system distributes all of the data records that are valid for at

least one day between the 'start date' and 'end date'.

For a complete data transfer you must use insert mode. For

consistency reasons we recommend that you use the reporting period

'All'.

o Update (Change) for Period

You can specify a reporting period (data selection period). The

system distributes the data records of the infotype/subtype to be

entered that are completely within this period. In the target

system, data records of the entered infotype/subtype that are

completely within this period are deleted (relationships are only

deleted if they were created earlier by distribution, see below:

local relationships). The distributed data records are then created.

In particular, this logic ensures that deleted data 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 lock

specific object types/infotypes/subtypes for import.

You completely lock object types for import by entering an existence

infotype:

Lock object type P by entering infotype 0000, object type AP by entering

infotype 4000, PD object types by entering infotype 1000.

Size of IDoc

Each IDoc transfers a maximum of 200 objects. You can reduce this number

with an entry in table T77S0: ALE BSIZE.

Change Pointers

To distribute changes after a complete transport, you can use change

pointers. Once they have been activated (in the IMG), change pointers

can be dispatched periodically using report RBDMIDOC.

You can display change pointers

and process them again, if necessary.

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:

Filter 2 for Distribution of HR Master Data:

To determine the filter values for each HR master data record, you must

implement a BAdI: Display Documentation

Serialization

For distribution, you can implement serialization. See also the relevant

section in the IMG.

Activate Serialization in ALE Inbound Processing:

Activate Serialization in ALE Outbound Processing:

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:

You can display the counter status of the registry in ALE outbound

processing:

SAP Enhancements as Function Exits

Under the SAP enhancement RHALE001 are function exits that you can use

in 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 error

handling in ALE inbound processing.

Component for Notes and Error Messages

Notes for ALE distribution of HR master data are stored under the

component BC-BMT-OM-ALE. You must also use this component when reporting

error messages in this area.

Restrictions:

HR master data has just one central HR System in which all HR components

are integrated. Distributed HR master data must not be changed in the

receiving system. Profiles with read authorization only, for example,

enable you to ensure that distributed HR master data is not changed in

the receiving system. Alternatively, you can use the original system

mechanism 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 in

the sending system. If the active plan version is not selected in the

sending system, the distribution program displays an error message.

Only the object type, infotype, subtype, or related object type can be

used as a filter. This means that data cannot be filtered in accordance

with any other fixed organizational criteria if there is more than one

receiving system. However, you can define customer-specific filters. For

more information, see the "Generic Data Filtering" section above.

If you want to create additional HR master data records directly in the

receiving system (such as a work center in Logistics), you must ensure

that the number range intervals are different from those in the sending

system.

Tasks (object types T, W) and responsibilities (object type RY) are

not distributed. The relationship (infotype 1001) for these object types

can be distributed. This means, for example, that you cannot distribute

a standard task, but that you can distribute a relationship for a

standard 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 with

initial 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 is

included in the transport log. In this instance, the IDoc is assigned

status 52 (posting of application document incomplete) so that

incomplete transports are recognized. If the missing object is

distributed to the target system at a later date, the relationship is

created automatically in both directions, and is therefore complete. A

relationship to external objects (such as cost centers) is distributed

and 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 is

retained. This means that a relationship created locally (not by

distribution) in the target system is not deleted in update mode. On the

technical level, a distributed relationship can be recognized by the

fact that the value AL is entered as an ALE marker in the P1001-REASN

field.

PA data and PD data is saved (updated) in the target system without

checks (unlike in dialog or batch input). In particular, this means that

updated data is not validated (time constraint, time delimitation,

allowed values). What is more, no change pointers are written, the

transport connection and workflow connection are deactivated, dynamic

actions are not performed. You must take this into account when

transferring data from an interface to an external system. The external

system itself must itself ensure consistency and the correct format. For

more information, see SAP Note 134085.

If you want to use standard transactions in the target system to access

HR data, Customizing in the target system must be identical to the

Customizing in the sending system.

Lock in ALE outbound processing: in the sending system, a lock entry is

created for each object when data is sent. If objects are already locked

in the sending system (by a maintenance transaction, for example), they

are not dispatched. This is documented in the program log. You must

repeat the send procedure later.

Lock in ALE inbound processing: in the receiving system, a lock entry is

created for each object when data is received. If objects are already

locked in the receiving system, they are not updated. This is documented

in the status of the posted IDoc. You must repeat the posting procedure

later.

When PA infotypes are distributed, you must ensure that at least the

existence infotypes 0000, 0001, 0002, and 0003 for persons, or 0001,

0002, and 4000 for applicants, are distributed. For the distribution of

holder relationships (S-P), you must also distribute infotype 1001 for

persons.

In the sending system, you must have authorization (PLOGI, P_ORIGIN,

P_APPL, structural authorization for T77PR and T77UA) to display the

infotypes. For holder relationships (S-P), you must have authorization

to display person infotypes (P_ORIGIN) in the receiver system.

Infotype 0003 is only distributed by change pointers if it has been

changed in combination with one of the other PA infotypes that is

supported.

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 Organizational

Management' scenario, access the SAP Library and choose

Cross-Application Components -> Business Framework Architecture -> ALE

Business Process Library -> Human Resources -> Master Data Distribution

(Human Resources).

Requirements

Scenario 2 'Distributed Organizational Management' is based on Scenario

1 'Distribution of HR Planning Data and HR Master Data from a Central HR

System'.

This scenario is activated in T77S0: ALE REPLI.

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) and

the replication (which is created by distribution).

Initialization

To initialize the original system table, the following function must be

executed:

Initialization of HRMDORIGIN

To maintain HRMDORIGIN in expert mode, the following function must be

executed:

The original can be transferred to a different logical system.

Objects as Original or Replication

The main differences between the original and the replication lie in the

creation of change pointers and in inbound processing for distribution.

If an object is created in a logical system, that system is regarded as

the original system and the object is stored there as an original. If

the object is distributed, it exists in the target system as a

replication.

A relationship that is distributed is created in the target system with

the ALE marker (value AL in the P1001-REASN field), which flags it as

distributed.

An original can be maintained. A change pointer is written to distribute

the change. In insert or update transfer mode, an original is selected

and dispatched. It is then created in the target system as a

replication. This original is not overwritten during inbound processing.

A replication can be maintained. A change pointer is not written to

distribute the change because the change is local. In insert or update

transfer mode, a replication is selected and dispatched if the

'Distribute originals only' parameter has not been selected. It is then

created in the target system as a replication. This replication is

overwritten during inbound processing.

Report RHALEORIGLIST (transaction RE_RHALEORIGLIST) generates a list of

original systems for the selected objects.

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 update

transfer mode, the relationship is selected and distributed. It is then

created in the target system as a relationship with ALE marker (see

above). This relationship between originals is not overwritten during

inbound processing.

A relationship between two replications can be created and maintained.

Change pointers are not written for distribution. In insert or update

transfer mode, the relationship is selected and distributed. It is then

created in the target system as a relationship with ALE marker. This

relationship between replications is not overwritten during inbound

processing.

A relationship between an original and a replication can be created and

maintained. Change pointers are written for distribution, but only for

the original with a determinable relationship direction. This specifies

just one system, which prevents data from being distributed from both

systems in both directions.

The distributable relationship direction is defined in T77ALERELA.

The distributable relationship direction is assigned in T77ALECOMB to

the object type combinations for original and replication.

In insert or update transfer mode, the relationship is selected and

distributed. It is then created in the target system as a relationship

with an ALE marker. This relationship between original and replication

is 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 two

replications. Change pointers are not written for distribution. In

insert or update transfer mode, the relationship is selected and

distributed. It is then created in the target system as a relationship

with an ALE marker. This distributed relationship is overwritten during

inbound processing.

If a replication is processed, a dialog box containing the appropriate

information can be displayed in dialog mode. This function is activated

by an entry in table T77S0: ALE POPUP.

Example

There are two systems, A and B, each with activated change pointers and

distribution to the other system using change pointers.

Objects O 4711 and O 4712 have been created in system A and distributed

to system B using change pointers, or insert or update transfer mode.

Object O 4713 has been created in system B and distributed to system A

using 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 for

object O 4711. The object is an original, so change pointers are

written.

Distribution by change pointer distributes the changed data from O 4711

in system A to system B. System B contains object O 4711 as a

replication, so distribution overwrites the data in object O 4711 in

system B.

Processing in System B for Infotypes that are not Relationships

In system B, infotypes 1000, 1002, and so on can be maintained for

object O 4711. The object is a replication, so change pointers are not

written.

Therefore, distribution by change pointer does not distribute the

changed data from O 4711 in system B to system A. The changes are local

and 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 from

object type O as the original to object type O as the replication with

relationship direction A.

All other relationships between the original and replication, even B002,

are not entered, which means they are not distributed by change

pointers.

Processing in System A for Relationships

Every relationship between original O 4711 and original O 4712 can be

maintained. Change pointers are written, and the relationship is

distributed to system B.

Every relationship between original O 4711 and replication O 4713 can be

maintained. For relationship 002, a change pointer is written for

relationship direction A002 from original O 4711 to replication O 4713,

and the relationship direction is distributed to system B. No change

pointers are written for any other relationships. In particular, a

change pointer is not written for relationship direction B002 from

replication O 4713 to original O 4711.

Processing in System B for Relationships

Every relationship between replication O 4711 and replication O 4712 can

be maintained. Change pointers are not written.

Every relationship between original O 4713 and replication O 4711 can be

maintained. Change pointers are not written. In particular, a change

pointer is not written for relationship 002 (see above) between original

O 4713 and replication O 4711 because relationship direction B002 has

not been entered as distributable by change pointer from original O 4713

to 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-Application Components

-> Business Framework Architecture -> ALE Business Process Library ->

Human Resources -> Master Data Distribution (Human Resources).

The original system mechanism is retrieved for persons and applicants in

the same way as for scenario 2 'Distributed Organizational Management'.

Requirements

Scenario 3 'Distributed HR Master Data' is based on scenario 2

'Distributed Organizational Management' and scenario 1 'Distribution of

HR Planning Data and HR Master Data From a Central HR System'.

This scenario is activated in T77S0: ALE REPPA

In ALE inbound processing, PD / PA integration is activated in T77S0:

ALE INTE

If a replication of a person or applicant is processed, a dialog box

containing the appropriate information can be displayed in dialog mode.

This function is activated by an entry in table T77S0: ALE POPPA

topic Re: Distributed HR Master Data (transaction PFAL in Application Development and Automation Discussions

Distributed HR Master Data (transaction PFAL

Re: Distributed HR Master Data (transaction PFAL

Re: Distributed HR Master Data (transaction PFAL

Re: Distributed HR Master Data (transaction PFAL