IDOC

1. How ALE and IDoc Affect SAP In-House Cash Configuration
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.
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.
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:

2. • 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 is below mentioned screen shot.
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

3. • 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.

4. Figure 2 Maintain logical systems
Step 2. Define the Target Systems for RFC Calls

5. Because SAP systems communicate via tRFC I 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 I 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.

6. 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.
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 is below mentioned screen shot.
• 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

7. 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

8. 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)

9. 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

10. 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.

11. 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

12. 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.

13. 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

14. 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.