Tcode:PFAL说明

Short text

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

• 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 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:

• 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'.

• 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.
Execute Function

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
Execute Function
and
process them again, if necessary.
Execute Function

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 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: 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
outbound processing: Execute
Function

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.
Execute Function

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
Execute
Function

To maintain HRMDORIGIN in expert mode, the following function must be
executed:
Execute
Function

The original can be transferred to a different logical system.
Execute
Function

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.

Execute
Function

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.
Execute
Function
The distributable relationship direction is assigned in
T77ALECOMB to the object type combinations for original and replication.
Execute Function
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.
Execute Function

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
Execute Function

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

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
Execute Function