PUBLIC

Decentralized EWM: Enhanced Settings for ALE

Data Transfer

Define enhanced settings for transfer to Decentralized EWM

Use

In this Customizing activity, you activate enhanced settings for data transfer (especially for Application Link
Enabling (ALE) filtering) to a decentralized Extended Warehouse Management (EWM) system based on SAP
S/4HANA.

For decentralized EWM, it might be the case that not all master data in the enterprise management system (for
example, SAP ERP or SAP S/4HANA) is required. You might want to transfer only materials that are maintained
for a certain plant or certain storage locations. Or you might want to transfer only customers or vendors of a certain
sales organization or purchase organization. With standard ALE filters, this is not always possible and
unnecessary master data can be transferred. The reason is that ALE filters that are not defined for the IDoc
header segment only filter out child segments, but not the parent segments. For example, a standard plant filter for
MATMAS-related message types only filters out E1MARCM segments, but not the complete IDoc. This
Customizing activity provides additional filtering that helps to filter out complete IDocs for certain ALE filters.

You can make these settings for each receiver system. For this, you have to enter a logical system, which
represents the receiving decentralized EWM.

You have to confirm that the receiver system is a decentralized EWM system by selecting the Decentral checkbox.
The system only takes the enhanced settings into account if you select this checkbox.

Caution

Select the Decentral checkbox only if the receiver system is a decentralized EWM system. It is not intended for
other use cases.

Note
ALE allows the usage of multiple filter groups in the distribution model.
If you use multiple filter groups together with the enhanced settings, further restrictions may apply.
These are listed below. If you use only one filter group per message type, the described restrictions
regarding multiple filter groups do not apply.

For each receiver system, you can activate the following enhanced transfer settings:

• Enhanced Material Filter

This setting influences how filters for plant and storage location in the ALE distribution model are used.
The differences effect the transfer using the following message types and reduced message types:

o MATMAS (material master)

If you enter ALE filters for plant (field WERKS) or storage location (field LGORT) in the ALE
distribution model, an IDoc is sent only if the material is maintained for the plant or storage
location.

If you use multiple filter groups for this message type, in addition to WERKS and LGORT only the
following filters of the header segment influence whether the IDoc is sent or not:
• Division (SPART)
• Material is configurable (MATKONFIG)
• Material Type (MTART)
• Material Group (MATKL)
• Competitor (MATKUNNR)

o BATMAS (batch master), CLFMAS (master object classification), MATQM (QM inspection setup)

If you enter these message types with a MATMAS related message type (including reduced
message types) as a dependent distribution in the ALE distribution model, the system also
 considers the filters for the plant and storage location of the dependent distribution. This means
that an IDoc is only sent if the material or plant or storage location matches the filters maintained
in the ALE distribution model of the referenced message type in the dependent distribution.

Example:
In the ALE distribution model, there is a reduced message type ZEWMMATMAS (based on
MATMAS) and you enter filters for plant 0001. In the same distribution model, you enter a
BATMAS message type and set a dependent distribution to the ZEWMMATMAS message type.
The system sends batches in BATMAS IDocs only for materials that belong to plant 0001.

If you use multiple filter groups for one of the following message types together with a
MATMAS related message type as a dependent distribution, and you have activated plant or
storage location filters, you can only use the following additional filter criteria for the message
types:

BATMAS ( Batch.SaveReplica )
• Material Group (MATL_GROUP)
• Material Type (MATL_TYPE)
• Plant (only applicable if batches are managed on plant level and plant is
contained in BATMAS IDoc)

CLFMAS:
• Class Type
• Object
• Table

MATQM ( MatInspectionControl.SaveReplica ):
• Plant

• Enhanced Customer Filter

o DEBMAS (Customer Master Data)

If you enter ALE filters for company code (field BUKRS), sales organization (field VKORG),
distribution channel (field VTWEG), or division (field SPART) in the ALE distribution model, an
IDoc is sent only if the customer is assigned to that company, sales organization, distribution
channel or division. If some of these criteria are defined together in the same filter group, the
customer needs to be assigned to all of the respective organizational units in order for an IDoc to
be sent.

If you use multiple filter groups for this message type, in addition to BUKRS, VKORG, VTWEG or
SPART only the following filter of the header segment influences whether the IDoc is sent or not:
• Account Group (KTOKD)

o ADRMAS (Distribution of Company Address)

If you enter an ADRMAS message type with a DEBMAS related message type (including reduced
message types) as a dependent distribution in the ALE distribution model, the system also
considers the filters for company code, sales organization, distribution channel, or division of the
dependent distribution. This means that an IDoc is sent only if the customer matches the filters
maintained in the ALE distribution model of the referenced message type in the dependent
distribution.

Example:
In the ALE distribution model, there is a reduced message type ZEWMDEBMAS (based on
DEBMAS) and you enter filters for sales organization 0001. In the same distribution model, you
enter an ADRMAS message type and set a dependent distribution to the ZEWMDEBMAS
message type. In this case only customers that are assigned to sales organization 0001 are sent
in ADRMAS IDocs.

3
• Enhanced Supplier Filter

o CREMAS (Vendor Master Data)

If you enter ALE filters for company code (field BUKRS) or purchase organization (field EKORG)
in the ALE distribution model, an IDoc is sent only if the supplier is assigned to the company or
purchase organization.

If you use multiple filter groups for this message type, in addition to BUKRS or EKORG only the
following filter of the header segment influences whether the IDoc is sent or not:
• Account Group (KTOKK)

o ADRMAS (Distribution of Company Address)

If you enter an ADRMAS message type with a CREMAS related message type (including
reduced message types) as a dependent distribution in the ALE distribution model, the system
also considers the filters for company code or purchase organization of the dependent
distribution. This means that an IDoc is sent only if the customer matches the filters maintained in
the ALE distribution model of the referenced message type in the dependent distribution.

Example:
In the ALE distribution model, there is a reduced message type ZEWMCREMAS (based on
CREMAS) and you enter filters for purchase organization 0001. In the same distribution model,
you enter an ADRMAS message type and set a dependent distribution to the ZEWMCREMAS
message type. In this case only customers for suppliers that are assigned to purchase
organization 0001 are sent in ADRMAS IDocs.

• Enhanced Characteristics Filter

o CHRMAS (Characteristic Master Data)

You can use this filter to avoid transferring characteristics that are not relevant to decentralized
EWM.
If a distribution of classes (message type CLSMAS) is also maintained for the decentralized EWM
system, and you enter CLSMAS class types as filters for this (field KLART), then a characteristic
is transferred if only it is contained in at least one class with this class type.

Example:
In the distribution model, there is a CLSMAS and you maintain class types 022 and 023 as filters
for it.
There is a characteristic COLOR and a characteristic CH-100.
Class CL1 is of class type 022 and uses characteristic COLOR. Class CL2 is of class type 001
and uses characteristic CH-100.
Only the characteristic COLOR is transferred.

• Immediate Batch Replication

You can select this checkbox to switch on immediate automatic transfer of changed or newly created
batches to a decentralized EWM system. The data is transferred using IDocs in an ALE distribution
model.
‘Automatic’ means there is no need to start or schedule a report, nor is a user required to use a
transaction for the transfer. Instead, the enterprise management system recognizes batch changes and
triggers the distribution, for example by using the master data transaction for batch creation or when
creating a batch together with an inbound delivery.
‘Immediate’ means that there is no time gap between the batch change and the data transfer to the
connected decentralized EWM system (see the Partner Profile Settings section) as there would be for a
scheduled report, for example.
Note that the filters maintained in transaction BD64, Maintenance of Distribution Model are used for the
distribution of BATMAS IDocs. Note that there is usually dependent distribution on the reduced message
type for the transfer of materials, ZEWMMATMAS, which means that material filters will also be evaluated
for BATMAS IDocs.

4
 o Prerequisites

As the transfer is based on the ALE framework, the same preconditions as for transferring batch
master data via BATMAS message types are required for this scenario. For example:
You need to make sure that the materials for which batch data shall be created or changed have
been transferred to decentralized EWM using standard ALE mechanisms. This is to ensure
successful inbound processing of BATMAS IDocs in EWM.
If you are using batches or materials with classification data, make sure that the classes and their
characteristics have already been transferred to EWM using standard ALE mechanisms in
advance.
Note that the required minimum standard for the basic message type is BATMAS03.

o Change Pointers

The trigger for the batch transfer is based on the batch change itself and does not rely on change
pointers. Therefore you do not have to use change pointers for this scenario. However, if change
pointers are activated or available in the system, this scenario will not consume them and thus
will not influence other scenarios relying on batch change pointers. Therefore, if you do work with
change pointers, redundant distributions to the same decentralized EWM system might occur.

o Partner Profile Settings

In order to achieve immediate replication of batches (instead of only IDoc creation without
transfer) you need to ensure that the Output Mode in the Outbound Options for BATMAS IDoc for
your decentralized EWM system is set to Process IDoc Immediately or Pass IDoc Immediately
instead of collecting outbound IDocs. You can make these settings in transaction WE20, Partner
Profiles.

o Monitoring

The creation of IDocs is triggered with a transactional Remote Function Call (tRFC) to ensure fast
dialog response times. You can monitor these calls in transaction SM58. You can also use
standard mechanisms for IDoc monitoring.

Besides the enhanced features described here, indicating that a receiver system is a decentralized EWM system
also ensures that other data transfers are optimized for decentralized EWM. For example, in the batch master data
(BATMAS), the system includes the classifications because they are required for decentralized EWM.

www.sap.com/contactsap

© 2021 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.