How ALE and IDocs Affect SAP in-House Cash Configuration

How ALE and IDocs Affect SAP In-House Cash Configuration  

by Juergen Weiss, SEPA-Now Consulting (March 2010)

Become familiar with the configuration of the Application Link and Enabling (ALE) settings of SAP In-House Cash. Follow a step-by-step technical implementation of ALE to enable the structured exchange data via Intermediate Documents (IDocs) within SAP In-House Cash. Become familiar with the most important IDoc types and their use in SAP In-House Cash. Understand how you can test the correct ALE configuration within the SAP system.

Categories: Cash Management, FSCM, Financials

Key Concept

SAP In-House Cash allows corporate cash and treasury management departments to set up a payment factory and to centralize their payment flows. One of the challenges is that the business processes of SAP In-House Cash span multiple financial components and require a broad set of business and technical skills.

SAP In-House Cash can help corporate treasurers or cash managers get a faster overview of their liquidity position and achieve a higher degree of transparency of their cash flows. Multinational organizations can centralize their group cash flows and establish an in-house bank. In most cases SAP In-House Cash is deployed on a separate instance than SAP ERP Financials and has to be connected to various other SAP systems within the group. To enable the structured exchange of data between distributed SAP (or non-SAP) systems, SAP In-House Cash uses Application Link Enabling (ALE). It is the technical basis for SAP In-House Cash, but very few SAP professionals are familiar with this technology and the necessary settings to configure SAP In-House Cash. I’ll provide a step-by-step introduction to explain these settings and make you familiar with some of the ALE and Intermediate Document (IDoc) basics to better understand the configuration of SAP In-House Cash.

Note

For another reference about SAP In-House Cash and in-house banks, see Aylin Korkmaz’s article “In-House Cash Center Manages Payment Processes,” which was posted to the Financials Expert knowledgebase in May 2004.

Some ALE and IDoc Basics

There are essentially two ways to technically link two SAP systems via ALE:

1. If the systems are independent, you implement a loosely coupled technical integration. In the case of a communication error or if the called system is unavailable, the calling system can continue to work. In this case, system-to-system communication is happening largely on an asynchronous basis and messages are exchanged between the systems. The data format that the SAP system uses for the asynchronous ALE communication is called IDoc. The technical communication between SAP systems is based on transactional Remote Function Calls (tRFC).

2. If you decide to establish a narrow coupling between SAP systems you require the called system to always be available. The technical basis is synchronous calls of a remote-capable function module in the target system. Such synchronous calls are suitable for verifying or reading data in other systems.

Since the SAP In-House Cash business scenarios are not suitable for the narrow coupling shown in option 2, I’ll focus on the first option in this article.   

SAP In-House Cash is based on asynchronous communication that takes place between SAP In-House Cash, the SAP system with the general ledger of the headquarters, and the SAP systems of the subsidiaries with the respective financials systems. Some of these systems may not exist in your system landscape (e.g., if you decide to run the SAP In-House Cash system and the general ledger on a single instance), but the basic ALE configuration is always the same.

The data format that is used for asynchronous ALE communication between logical SAP systems is the IDoc. An IDoc represents a configuration of an IDoc type that determines the IDoc structure and indicates the SAP data format that is used to transfer the data for a business transaction. Each IDoc consists of a header, several data segments, and status records. The IDoc header contains the contents, structure, sender, receiver, and current status of the IDoc.

Each data segment contains a standard header consisting of a sequential segment number, a description of the segment type and a 1000 character long string field containing the actual data of the segment. The status records show the history of the system processing steps applied to the IDoc so far. The format is identical for each IDoc type.

You can display IDoc types by following this menu path Tools > ABAP Workbench > ALE > ALE Development > IDoc Types. You use the following IDoc messages and message types for the communication between SAP In-House Cash and other SAP systems:

FINSTA (IDoc message type FINSTA01) for account statements from the in-house cash center (IHCC) to the various affiliates

PAYEXT (PEXR2002) for payment orders from the various affiliates for the IHCC or the payment order from the IHCC to the clearing partner

DIRDEB (PEXR2002) for direct payment orders from the various affiliates for the IHCC or the payment order from the IHCC to the clearing partner

FIDCC2 (FIDCCP01) for financial transaction data between the IHCC and the general ledger of the headquarters

To configure the communication between the various SAP systems, you need an ALE distribution model. The ALE distribution model identifies the logical SAP systems and describes the message flow between these systems. It also defines which IDoc messages are exchanged between the logical systems. You can access the configuration of the ALE distribution model by following IMG menu path SAP NetWeaver > Application Server > IDoc Interface/Application Link Enabling (ALE) > Modeling and Implementing Business Processes > Maintaining the Distribution Model. You can also use transaction SALE, which provides you with a submenu containing all relevant

ALE configuration steps (Figure 1).

Figure 1 Transaction SALE with all ALE configuration settings

To configure ALE settings, carry out the following configuration steps in the SAP In-House Cash system in this order:

Step 1. Define the logical SAP systems and assign them to a client Step 2. Define the target systems for RFC calls Step 3. Maintain the ALE distribution model Step 4. Generate partner profiles Step 5. Distribute the ALE model view Step 6. Maintain the partner profiles for business partners

In the following sections, I describe these six steps in detail. The only prerequisite for this configuration is that you have already created the SAP In-House Cash business partners (e.g., clearing partner).

Step 1. Define the Logical SAP Systems and Assign Them to a Client

You need to define logical systems because they uniquely identify SAP systems within an ALE distribution model. One logical system corresponds to a client. Once you have assigned a logical system you can’t change the assignments anymore. You have to maintain logical systems (e.g., the development, quality, and productive systems) for your entire SAP landscape and you can’t transport these entries between the SAP systems. A naming example for a logical system could be IHCDCLNT020 (for the development system). You can maintain logical

systems via transaction SALE or transaction SCC4 (Figure 2). If you want to identify the logical system of your own client, look up field LOGSYS in table T000.

Figure 2 Maintain logical systems

Step 2. Define the Target Systems for RFC Calls

Because SAP systems communicate via tRFC you have to maintain appropriate RFC destinations for the SAP systems of your subsidiaries. If the head office’s FI system is not in the same client as SAP In-House Cash, you need to create a RFC destination for FI as well. RFC connections are maintained by following the IMG menu path SAP NetWeaver > Application Server > IDoc Interface/Application Link Enabling (ALE) > Communication > Create RFC Connections, or by using transaction SM59. Make sure that the name of the RFC connection is exactly the same as the name of your logical system you created before.

There are different connection types in the SAP system, but in this case you have to select type 3, which is relevant for SAP connections. Under the tab strip Technical Settings, you need to enter the server name of the

target machine to which you want to connect (Figure 3). Select the Hostname radio button in the Save to Database as section because the IP address might change in the case of a system migration.

Figure 3 Create RFC destinations

Enter the client as well as the RFC user and its password under the Logon & Security tab. Once you’re done with this you can test whether this user is valid on the target system by clicking the Connection Test button.

Step 3. Maintain the ALE Distribution Model

You need to assign the various logical systems and the message types that are exchanged within an ALE distribution model. Do this by following IMG menu path SAP NetWeaver

> Application Server > IDoc Interface/Application Link Enabling (ALE) > Modeling and Implementing Business Processes > Maintain Distribution Model and Distribution Views or by using transaction BD64.

Note

If SAP In-House Cash and your subsidiary companies are in the same client, you can ignore step 3. You would have to create a transactional RFC port instead with transaction WE21. Since this is rather uncommon, I focus on the ALE distribution model in this article.

Choose a meaningful name for your ALE distribution model and click the Add message type button. You now have to enter the settings for the three IDoc message types you need within SAP In-House Cash: FINSTA, PAYEXT, and DIRDEB. The settings are similar (Figure 4):

Model view (the technical name of the model view you created) Sender (the logical name of either the head office or the subsidiary) Receiver (the logical name of either the head office or the subsidiary)

Message type (FINSTA, PAYEXT, or DIRDEB)

Figure 4 Add IDoc message types to an ALE distribution model

The sender and receiver depend on the message type. In the case of bank statement FINSTA, the sender is the logical system of the head office and the receiver is the logical system of the subsidiary. In the case of the payment

order PAYEXT and the direct debit authorization DIRDEB it is the other way around – the sender is the logical system of the subsidiary and the receiver is the logical system of the head office.

Step 4. Generate Partner Profiles

Create the partner profiles for the communication between the logical systems. Use transaction BD82 or follow IMG menu path SAP NetWeaver > Application Server > IDoc Interface/Application Link Enabling (ALE) > Modeling

and Implementing Business Processes > Partner Profiles > Generate Partner Profiles (Figure 5). You have to define the ALE distribution model and execute this report on every system locally. Choose the option Transfer IDoc immediately.

Figure 5 Generate partner profiles

Step 5. Distribute the ALE Model View

Go back to transaction BD64 and select the change view of the ALE distribution model. Mark your model view and select Edit > Model view > Distribute and mark the subsidiary system as target system. Afterwards, check the subsidiary system to see whether the ALE distribution model has been distributed. For technical purposes, the SAP system generates the message type SYNCH in the partner profiles of the partner type LS (logical system) in the outgoing direction. Therefore, you don’t need to create the message type SYNCH in your model view.

Step 6. Maintain the Partner Profiles for Business Partners

In the final configuration step you manually maintain the partner profiles. Follow menu path Tools > ALE > ALE Administration > Runtime Settings > Partner Profiles or use transaction WE20. In this case, focus on partner types

GP (business partner) and LS (logical systems) because they’re the relevant ones for SAP In-House Cash. First,

you have to create an entry for the business partner. Select GP and click the create icon (Figure 6).

Figure 6 Create a business partner profile

Maintain the following settings:

Partner number (number of the business partner of the headquarters) Partner type: US (user) Agent (enter the ID of the user who should be informed via workflow if an IDoc has errors) Language (language of the user)

Now you need to create the inbound parameters for the message types DIRDEB and PAYEXT as well as the outbound parameters for the message type FINSTA. To do this, click the plus icon below the table of the inbound

parameters, which becomes visible after you have saved your entries. Use the parameters in Table 1 for the two inbound message type entries. You can also copy the PAYEXT entry to make data entry a bit easier.

Table 1 Inbound parameters for the message types PAYEXT and DIRDEB 

Click the plus icon below the table of the outbound parameters and enter the values in Table 2 for the message type FINSTA. You have two options for the output mode: Transfer IDoc immed. (immediately) or Collect IDocs

(Figure 7). If you select the second option, you have to create a batch job for the SAP program RSEOUT00.

Table 2 Outbound parameters for the message type FINSTA

Figure 7 Maintain the outbound FINSTA parameter for a business partner

The second relevant partner type is LS. For this, you also need to create inbound parameters for message types PAYEXT and DIRDEB, as well as the outbound parameters for the message types DIRDEB, PAYEXT, and SYNC. Create the nodes for the two inbound parameters with the plus icon. Then, for the two inbound message types

entries, use the parameters shown in Table 3.

Table 3 Inbound parameters for the message types PAYEXT and DIRDEB

If your head office’s FI system is not in the same client as SAP In-House Cash, you must also maintain the

inbound parameter shown in Table 4.

Table 4 Inbound parameters for the message types FIDCC1 and FIDCC2

For the outbound parameters, you have to maintain for the message types DIRDEB and PAYEXT the entries

shown in Table 5.

Table 5 Outbound parameters for the message types PAYEXT and DIRDEB

For the third outbound parameter, enter one more entry for the message type SYNC with the attributes in Table 6.

Table 6 Outbound parameters for the message type SYNC

If your head office’s FI system is not in the same client as SAP In-House Cash, you must also maintain the

additional outbound parameter shown in Table 7.

Table 7 Outbound parameters for the message types FIDCC1 and FIDCC2

ALE Configuration in the SAP System of the Subsidiary

The same six steps that I showed you are required to configure the ALE settings in the SAP system of the subsidiaries that communicate with SAP In-House Cash. You have to make these entries for inbound and outbound message types for each subsidiary company that communicate with SAP In-House Cash.

The first five steps are similar. The only difference is that you enter all settings for the subsidiary instead of the head office. In step 6 you need to create only one partner profile for B (bank). You have to create the in-house bank with transaction FIHC. You can’t create these partner profiles for the in-house bank if you haven’t first created a house bank with transaction FI12. The partner type settings for B are the same as above with BP. You need to create an inbound parameter for the message type FINSTA and two outbound parameters for the message types PAYEXT and DIRDEB. The settings for the inbound parameter are shown in Table 8. The settings for the

outbound parameter are shown in Table 9.

Table 8 Inbound parameter for the message type FINSTA

Table 9 Outbound parameters for the message types PAYEXT and DIRDEB

The settings for the business partner type LS (logical system) are the same as for the business partner type B and you can simply copy them. If the subsidiary is in the same system as SAP In-House Cash, you basically send IDocs to the same SAP system. In this case, the message types PAYEXT, DIRDEB, and FINSTA of the partner type LS have identical inbound and outbound parameters. With this final step, the ALE settings in both the head office’s system and the subsidiary systems are complete.

Juergen Weiss works in the functional area of SAP Financial Supply Chain Management. As part of SAP’s product management team, he was globally responsible for the SAP FSCM applications, including Electronic Bill Presentment and Payment, Dispute Management, Collections Management, Credit Management, Treasury and Risk Management, Bank Relationship Management, In-House Cash, and Accounts Payable and Receivable. You may contact Juergen via email at [email protected].