Release Notes for ALE Scenarios and Technology, Release 4.0A


As part of Business Framework several stand-alone application components that are coupled with other R/3 Systems are being delivered in Release 4.0A. Enhancements have also been made to existing scenarios.

ALE technology has been enhanced to support synchronous BAPI calls as well as asynchronous BAPI calls and also to support the serialized distribution of dependent master data.

Refer to ALE online documentation for descriptions of the scenarios and technology.

New Menu Path for ALE Functions

As of Release 4.0A, ALE functions - distribution of application transaction data, distribution of master data, ALE administration, and ALE development, are located under Tools -> Business Framework -> ALE.


The majority of interfaces between Human Resource Management and Logistics and Accounting used within an R/3 System are now also supported in a distributed environment.


As of Release 4.0A the component Treasury is being delivered as part of the standard release. This means that the components Treasury Management and Market Risk Management can run in an integrated system or in stand-alone systems. In the latter case ALE provides the interfaces to Accounting. A stand-alone solution has been available since Release 3.0.

The PDM (Product Data Management) scenario enables product development and design to be managed in a different R/3 System than the production itself. For this, additional master data interfaces have been created which are listed below.


New interfaces for master data have been added and extended in the PDM scenario:

When a customer is assigned to a class for distribution, a change pointer is automatically created to distribute the complete master data object. This ensures that the details of newly created customers are passed to the receiving system when customer master data is filtered via classes.


Distribution of Credit Data for Credit Limit Check in Sales and Distribution

The A/R summary can be distributed periodically from an accounting system into a sales and distribution system where a credit limit check can be carried out. The A/R summary briefly describes the current status of a credit management account for the accounting department. In order to distribute credit data there can only be one credit control area for the sales and distribution system.

The sales and distribution system can also query the current credit status asynchronously in the accounting system.

Separation of Sales and Shipping Scenario Enhanced

Further data relevant to delivery is sent from the sales system to the shipping system and taken into account in delivery.


Delivery Interface Enhanced

There are new interfaces for deliveries, packing dates and pickings. For further information refer to the Release Notes on the delivery interface. New/Enhanced EDI Interfaces in FI

Function Message Type IDoc Type
Account Statement FINSTA FINSTA01

New/Enhanced EDI Interfaces in MM

Function Message Type IDoc Type
Forecast delivery schedule DELINS DELFOR01
JIT delivery schedule DELINS DELFOR01
ERS w/ invoice verification GSVERF GSVERF01
Settle consignment w/ invoice GSVERF GSVERF01
Import Data Declaration IMPINV IMPINV01
Despatch advise DESADV DELVRY01

New/Enhanced EDI Interfaces in SD

Function Message Type IDoc Type
Carrier notification CARNOT DELVRY01
Despatch advise DESADV DELVRY01
Shipping order SHPORD DELVRY01
Warehouse order WHSORD DELVRY01
Shipment message SHPMNT SHPMNT02
Export Data Declaration EXPINV EXPINV02
MAIS pick-up sheet DELORD ORDERS03
Shipping confirmation SHPCON DELVRY01
Warehouse confirmation WHSCON DELVRY01


BAPI Integration; Creating an ALE Interface from a BAPI

BAPIs can now be used for synchronous as well as for asynchronous communication between systems. With synchronous communication a synchronous RFC is transmitted between the systems. With asyncronous communication data is transferred using IDocs. A new Tool has made this possible which developers can use to generate an ALE interface from a BAPI. This is documented in the ALE Programmer's Guide.

What Does the Term 'Logical System' Mean?

As of Release 4.0A a logical system is treated as an organization unit. The assumption is that logical systems are assigned in the development system or in the test system and these are then transported into the productive system.

This means that productive systems have the same logical system names as the corresponding test systems.

If a customer is already using different names for the test system and productive system, the names do not need to be changed.

Distribution Model

Distribution model maintenance in the R/3 System has been thoroughly enhanced. You can now model BAPI communication links as well as IDoc communication links.

You can now make the distribution of a message type dependent on another message type. This makes it possible, for example, to send the classification data of a material to the same logical system that the material is sent to.

The distribution model is now connected to the transport system so that the model can simply be transported from the test system into the productive system.

The PC Tool 'OA' is no longer supported.

A BAPI 'DistributionModel.GetInfo' has been created for Release 4.0A with which you can read information on the distribution model. We will be providing a Visio add-on in SAPnet which enables you to view the distribution model graphically in Visio. This add-on has been written in Visual Basic which means that the presentation is interactive.

Serialization of Dependent Objects

If there are dependencies between objects as there is between classification and material in the example above, newly created objects must be created in the correct sequence in the target system. So, for example above, material comes before classification.

In 4.0A this is achieved with new reports that can send IDocs or process IDocs in the target system in the correct order.

Enhancements to the Name Range

As of Release 4.0A you can give longer names to many development objects. The IDoc interface used by ALE supports the enhanced name range whilst ensuring that name ranges from earlier releases are compatible. For further information refer to the Release Notes on

EDI Basis Development. Work Item Text Can Be Refreshed

In inbound processing a work item is created if the IDoc could not be posted in the application. The IDoc is then assigned the status 51. If the error is cleared, the IDoc processed again, but another error occurs, the short text of the work item has not yet been updated. This short text is being updated for 4.0A.

RFC: Same User in Several Systems

For RFCs, the user used in the target system is defined in the source system and is transferred when the RFC destination is specified. This enables 'trusted' systems to be defined and the current dialog user to be transferred. That means if a user "Smith" uses a transaction in System "A" that transmits an RFC to system "B" so that he/she can continue to work there, then user "Smith" is used in system "B". This is especially important for authorization checks.

Application Server Deadlock Problem Solved With Immediate Processing

The problem described in Note 52476 no longer occurs if the new inbound function module IDOC_INBOUND_ASYNCHRONOUS is called. This function module is called if a 4.0A system calls another 4.0A system and the outbound port has been configured accordingly.

The Locking Logic of Customizing Objects Changed When Modelling Control Data

When you model control data distribution, certain customizing objects may be locked in an R/3 System. In Release 3.X relevant a customizing object for distribution could only be maintained in the systems that dispatch the object. As of Release 4.0A a customizing object can be maintained in all the systems that do NOT receive the object from an external system.