Example of Master Data Distribution 

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

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

If maintenance is central, copy management is performed directly in the decentralized systems. If there are several maintenance systems (for example, one for each view of the material), copy management is handled in the reference system. The reference system then distributes the master data changes to all the other decentralized systems.

Messages can be sent in one two ways:

●     If PUSH type distribution is used, data is exchanged using the MATMAS message type. (This message contains the material master data to be distributed).

●     If PULL type distribution is used, the MATFET message type is sent from the material master copy management to the material master maintenance original. (This message is a request to the original to send material master data.)

The following filters control the distribution:

Classes (for example, distributing classified material numbers to specific systems).

●     Filter objects: organizational units (sales organization, plant).

As part of the ALE Customizing process 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 the system checks that the modified field and the table are 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. In ALE Customizing, customers can specify the fields that need to be distributed.

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 the background. A background job should be scheduled for each message type.

Depending on the settings in the partner profiles, it may be necessary to send IDocs directly by executing the program RSEOUT00. The background job that executes the RBDMIDOC can do this in a second step. For further information about these functions, see:

 

Periodic Jobs

 

 

When creating a master IDoc ensure that:

●      The master IDoc contains all the IDoc segments whose fields have changed.

●      The master IDoc contains all the mandatory IDoc segments

●      The parent segments of these segments are dispatched

●      IDoc segments are sent complete, in other words, data must be entered in all fields.

Notes on Reading Changes

When inbound master data is processed, you can prevent the contents of sender fields overwriting fields in the receiver system. You can find out how to make this setting in the IMG:

 Application Server
    IDoc Interface/Application Link Enabling (ALE)
    Modelling and Implementing ALE Business Processes
      Converting Data Between Sender and Receiver

For IDocs with message types MATMAS, DEBMAS or CREMAS and all other IDocs which use CALL TRANSACTION for inbound processing, no fields will be overwritten in the receiving SAP system if the constant “/” is specified in the IDoc field.