SAP ABAP IMG Activity OALE_LO_DEKR_0003 (Proposal for distribution model: Customer and vendor masters)

Hierarchy

☛

SAP_APPL (Software Component) Logistics and Accounting
⤷

CA-BFA-ABL (Application Component) ALE Business Process Library
⤷

DALE (Package) ALE Application

IMG Activity

ID	OALE_LO_DEKR_0003	Proposal for distribution model: Customer and vendor masters
Transaction Code	S_ALR_87008560	IMG Activity: OALE_LO_DEKR_0003
Created on	19981222
Customizing Attributes	OALE_LO_DEKR_0003	Proposal for distribution model: Customer and vendor masters
Customizing Activity	OALE_LO_DEKR_0003	Proposal for distribution model: Customer and vendor masters

Document

Document Class	SIMG	Hypertext: Object Class - Class to which a document belongs.
Document Name	OALE_LO_DEKR_0003

The vendor master and customer master, and the contact person use central address management (ZAV).

Separate message categories (ADRMAS, ADR2MAS, ADR3MAS, see below) are assigned to addresses in the ALE environment, so that these can be distributed as independent objects.

Contact persons are not distributed separately. They are distributed as part of the customer master.

In the text below, the vendor master and customer master are also described as master object.

Regarding distribution, note that:

Address objects are processed before the master object in the target system. This ensures that the address data already exists when the master object is created, and that the master object is created with full address data. This would not be absolutely essential from the point of view of the master object, as the master object could be created with incomplete master data (the address data in the CAM tables is in part the same as that in the master object tables), but operative applications may need the full address data.
The address object and master object are sent to the same target systems. This ensures that address objects are not distributed to target systems in which the related master objects are not known.

Processing of address objects before the master object in a target system is achieved by serialization. This must be maintained for the message category of the address object and the message category of the master objects. Serialization ensures that a separate control message is sent to the recipient if the IDocs, created for the related message categories by a certain point in time in the sending system, are transferred to the target system successfully. The recipient function for the control message in the target system ensures that the IDocs that have built up by the starting date are posted in the message category sequence specified.

Notes:

Serialization groups have been created for the standard message categories for customers (DEBMAS, DEBCOR), vendors (CREMAS, CRECOR) and address objects (ADRMAS, ADR2MAS, ADR3MAS). During serialization group maintenance, you must ensure that the address objects are distributed before the master objects. Because addresses are distributed using different types (see below), you must ensure that addresses with type 1 are distributed before addresses with type 3, and these are distributed before addresses with type 2.
In the receiving system, you define inbound processing for each sending system for the message categories of a serialization group.
To use serialization, the IDocs must be parked in the sending or receiving system. It does not make sense to forward the IDocs directly. You maintain the relevant settings for this in the partner profiles.

You send the address and master objects to the same system by making the relevant settings in the distribution model. Before the distribution model is maintained, the objects to be distributed must be known.
Make use of the opportunity to set a default for distribution using automatic generation of distribution.
This default ensures that all entries are made that are necessary for the distribution of master objects and the addresses assigned to them in the ALE distribution model.

For generation of the distribution model, you must take the following points into consideration:

For the generated distribution to be visible in the distribution model, you must enter a name for the model view. You can then find the distribution generated in the distribution model under this name.
The logical system names of the systems between which data is distributed must be entered so that the partner relationship can be defined in the distribution model.
For distribution of master data, you must enter the relevant message categories (the message categories supplied are CREMAS and CRECOR for the vendor master and DEBMAS and DEBCOR for the customer master). A default for the customer or vendor distribution and related addresses is then generated.

For a better understanding of the generated distribution model, bear in mind the following information:
Central address management differentiates between 3 address types:

Address type 1: Addresses of companies and organizations (-> message category ADRMAS)
Address type 2: (New private) addresses of people (-> message category ADR2MAS)
Adress type 3: Addresses of people in companies (-> message category ADR3MAS)

The main address of a customer or vendor has address type 1. The address of a contact person had address type 3. For a contact person, you are able to maintain a different business address (address type 1) or a private address. The private address has either address type 1 (if it is an address that already existed before the address data was converted to CAM; also referred to here as an "old" private address) or address type 2 (all contact person private addresses that are created after the conversion to CAM; also referred to here as a "new" private addresses).
A method (SaveReplica) for distributing the address data of the particular type is available for each address type.
The message categories on which the methods are based are:

ADRMAS for addresses with type 1
ADR2MAS for addresses with type 2
ADR3MAS for addresses with type 3

You can use the filter objects assigned to these methods to define criteria for whether an address is distributed via this message link. Filter objects can be logically linked to each other via filter groups. An "or"-link exists between various filter groups. Within a filter group, the filter objects are connected by "and"-links.

The following filter groups and related filter objects must be maintained for addresses with address type 1:
For each message category of a customer/vendor, a filter group must be created for the company address. This filter group must contain the following filter objects:

Semantic meaning of the address
Object type of the object owner (customer or vendor)
Object ID of the object owner

(As a dependency is defined for the object ID between the method SaveReplica and the standard message category of the customer/vendor, you enter the message category of the customer/vendor here).

For each message category of the customer, a filter group for the different business address and the "old" private address is to be created for each contact person. This filter group must contain the following objects:

Semantic meaning of the address
Object type of the object owner (contact person)
Object type of the object to which the contact person references (customer)
ID of the referenced object.

(As a dependency is defined for the object ID between the method SaveReplica and the standard message category of customer, you enter the message category of the customer here.)

The following filter groups and related filter objects are to be maintained for addresses with type 2:

For each message category of a customer, a filter group is to be created for the "new" private address for the contact person. This filter group must contain the following filter objects:

Semantic meaning of the address
Object type of the object owner (contact person)
Object type of the object which the contact person references (customer)
ID of the referenced object

(As a dependency is defined for the object ID between the method SaveReplica and the standard message category of the customer, you enter the message category of the customer here.)

The following filter groups and related filter objects are to be maintained for addresses with type 3:
For each message category of a customer, a filter group is to be created for the contact person address for the contact person. This filter group must contain the following filter objects:

Semantic meaning of the address
Object type of the object owner (contact person)
Object type of the object a level above the contact person (customer)
ID of this higher-level object

(As a dependency is defined for the object ID between the method SaveReplica and the standard message category of the customer, you enter the message category of the customer here.)

Further notes

For details on carrying out the above-mentioned serialization, see the step Data Serialization for Sending and Receiving in Customizing for ALE.

For details on maintaining the above-mentioned distribution model, see the step Maintain Distribution Model in Customizing for ALE.

As this may lead to the creation of a further default for distribution that needs to be maintained, the default is not transported.
It is possible to transport the distribution model in

Business Attributes

ASAP Roadmap ID	204	Establish Functions and Processes
Mandatory / Optional	2	Optional activity
Critical / Non-Critical	1	Critical
Country-Dependency	A	Valid for all countries

Assigned Application Components

Documentation Object Class	Documentation Object Name	Current line number	Application Component	Application Component Name
SIMG	OALE_LO_DEKR_0003	0	HLA0001520 O HLA0001521 O HLA0001263 O HLA0001274

Maintenance Objects

Maintenance object type

Customizing Object

Assigned objects
Customizing Object	Object Type	Transaction Code	Sub-object	Do not Summarize	Skip Subset Dialog Box	Description for multiple selections
IMGDUMMY	D - Dummy object	WYL2	00000001			Create Proposal for Distribution Model

History

Last changed by/on	SAP	19990204
SAP Release Created in

Object Hierarchy

Used by

Advertise Links