Example of Master Data Distribution

The material master maintenance is used here as an example to explain the master data distribution. All the scenarios for master data distribution are constructed in a similar way to the material master data distribution.

Distribution Scenario for Material Master Data Distribution

The material master maintenance and material master maintenance (copy) function types are located in distributed systems.

The copy management is performed directly in the decentral systems if maintenance is central. If there are several maintenance systems (for example, one for each view on the material), then the copy management is performed in the reference system. This then distributes the master data changes to all the other decentral systems (message (2) in the graphic).

Messages are sent between these function types.

The following filters control the distribution:

Part of the ALE Customizing process is that the customer specifies in the distribution model which fields in which application table are relevant to the distribution for each message type.

Distribution Model - Material Master Data Distribution. The "plant" filter object is used in the graphic above. Since plant 001 is managed in the LYON system, LYON receives the material master data for plant 001.

Checking Whether Distribution Is Required

The contents of the change document are passed from the change document system to the SMD Tool. For each document item a check is made of whether the combination of changed field and table is assigned to a message type.

Writing Change Pointers

If the fields are required for distribution, the SMD tool writes change pointers and stores them in the BDCP and BDCPS tables. Change pointers are basically the key fields of the table that contains the changed field. The customer can specify the fields that are relevant to distribution in the ALE Customizing.

Change pointers are created only if both ALE and the message type are active.

Sending Changes

To distribute changed master data change pointers have to be processed. Depending on the message type, the program RBDMIDOC creates the master IDocs and passes them to the ALE layer for dispatch.

For this you should use program RBDMIDOC. RBDMIDOC is usually automatically executed in a batch job. A batch job should be scheduled for each message type.

Depending on the configuration of partners' declarations it may be necessary to send IDocs directly by executing the program RSEOUT00. The batch job which executes the RBDMIDOC can do this in a second step. For further information about these functions refer to IMG.

When creating a master IDoc ensure that:

Notes on Reading Changes

When master data is being input, it is possible to prevent the contents of sender fields being copied over fields in the receiver system. To find out how to make this setting, read the IMG documentation in the Functions for IDoc processing ® Conversion section of the ALE customizing.

For IDocs with a message type of MATMAS, DEBMAS or CREMAS and all other IDocs which use CALL TRANSACTION for inbound processing no fields will be input if the constant "/" is specified in the corresponding IDoc field.