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|
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|
New/Enhanced EDI Interfaces in SD
|Function||Message Type||IDoc Type|
|Export Data Declaration||EXPINV||EXPINV02|
|MAIS pick-up sheet||DELORD||ORDERS03|
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 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.