SAP IDOC

Architecting IDOCS for External Business Partner Payments using IHC of FSCM

Applies to SAP ECC 6.0. For more information, visit the Enterprise Resource Planning homepage.

Summary This article illustrates architecting of idocs for third party payments using In-House Cash (IHC) functionality of Financial Supply Chain Management (FSCM). End to end business process from creation of vendor invoice to generation of payment file to banker is explained with screenshots from IHC perspective. SAP In-House Cash is used for processing internal and external payment transactions within a group or company. SAP IHC application component is connected to the FI (Financial Accounting) sub-system and uses its functions, such as the payment methods and payment program. The affiliated companies also use Financial Accounting (FI) functions. The starting point as detailed in this article would be the payment program run by the affiliated company code to clear vendor invoice which results in generation of payment orders to the in-house cash center through Idocs. Author:

Pon Karthikeyan Shanmugam

Company: Mahindra Satyam Created on: 18 May 2010

Author Bio The author is currently working with Mahindra Satyam as Senior Consultant in the area of SAP FICO, FSCM and PS. He has more than seven years of SAP implementation, roll-out and upgrade experience in SAP Financials, Analytics and Project system. He holds a masters degree in Business Administration and is SAP Professional Certified Consultant in SAP FI/CO.

SAP COMMUNITY NETWORK © 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1


Table of Contents Business Case .............................................................................................................................................. 3 Scope........................................................................................................................................................ 3 Solution Design............................................................................................................................................. 3 Partner Profile Maintenance....................................................................................................................... 3 Business Scenario ........................................................................................................................................ 7 Related Contents ........................................................................................................................................ 11 Disclaimer and Liability Notice ..................................................................................................................... 12




Business Case The objective of this article is to elucidate architecting of Idocs for payments made to external business partners using the In-House Cash Center to centrally process payments for participating affiliates. Accounts are managed in the in-house cash center on the basis of the payment items posted – in general automatically – to the account. The payments are entered by the affiliated companies and transferred by Idocs to SAP In-House Cash application component for posting. From the perspective of SAP In-House Cash, these payments fall under the category of third party payment transactions. Architecting Idocs configuration is the crucial link for the flow of data between affiliates and SAP In-House Cash Application component. While this article explains the set up of Idocs of relevant message types, care has been taken to ensure that the underlying business process is explained as well. Scope The scope of this article is limited to explanation of Idocs configuration of relevant message types used in externally initiated payment transactions of SAP In-House Cash Application Component of FSCM. In doing so, the core business process which supports the flow of data between Financial Accounting (FI) and IHC through Idocs have also been explained with respect to business scenario – external (third party) payments. Configuration details of entire set up of FIN-FSCM-IHC is outside the scope of this article. Please refer to http://help.sap.com/sap for broader understanding of IHC functionalities and set up. Configuration of RFC type connections and Port definition is also outside the scope of this article.

Solution Design Idocs of message types PAYEXT and EUPEXR are used in external payment transactions of IHC application component. Distinct partner numbers (logical systems) are created for loopback with respect to outbound idocs resulting from affiliates and inbound idocs that creates the payment orders and payment requests in inhouse cash center (message type PAYEXT). Partner Profile Maintenance A logical system need to be defined in the SAP system through transaction “SALE” which is then used in partner profile. For the purpose of our requirement, the screen shot below captures the definition of two logical systems used for message types PAYEXT and EUPEXR.

Idoc partner profiles are maintained in SAP transaction “WE20”. The screen shot below illustrates the maintenance of partner profile for message type PAYEXT with respect to logical system “LOCAL”.







Similarly partner profile is maintained for message type PAYEXT with respect to logical system “P01PERP100”.

The partner profile consists of several parameters such as receiver port, packet size, outmode and Idoc type. 1) Parameter “Receiver port” specifies how the idocs are transferred to the external system 2) Parameter “Packet size” denotes the number of idocs sent per RFC 3) Radio button “Transfer Idoc Immed.” in Output Mode specifies that Idocs are sent immediately and not stored in database to be sent later. If output mode “4” is used, then program “RSEOUT00” need to be scheduled as background job to collect and send the Idocs. 4) Parameter “Basic type” in Idoc Type refers to the Idoc type that is made available in the system by SAP. In ECC, basic type version PEXR2002 is used. It must be mentioned that the topic of Idocs with message type “EUPEXR” is of special importance here. EUPEXR Idocs are created when outbound PAYEXT Idocs are generated from FI to FSCM-IHC sub-system. This is part of standard FIN-FSCM-IHC functionality and partner profile need to be maintained for EUPEXR message types.




Message EUPEXR forms the logical unit around the PAYEXT Idocs. Program RFFOEDI1 always generates EUPEXR messages. We cannot deactivate this function and hence partner profile should be maintained for EUPEXR.




Business Scenario The starting point for central payments from in-house cash center to external business partners is processing of vendor invoices for payments by participating affiliates. Let us say for example that an FI invoice created through transaction FB60 is selected for payment run through transaction F110 by the participating affiliate. Screen shot below details the FI invoice that would be used in the payment program in F110 by the participating company code to send payment orders to the in house cash center. In the example below, FI invoice 1200000626 in CC1000 for an amount of USD 1.00 only is used in the payment program

The above invoice is processed for payment through transaction F110 in CC1000 which results in creation of Idocs enabled by the variant settings maintained in program RFFOEDI1.




The successful execution of payment program results in creation of one outbound PAYEXT Idoc, one inbound PAYEXT Idoc and one outbound EUPEXR Idoc.

In order to better appreciate the process flow, segments E1IDKU3 and E1IDPU5 of the inbound PAYEXT Idoc 15088597 are captured in the screen shots below.




This is the transitory point where data flow from Financial Accounting (FI) to IHC application component of FSCM is achieved. With the creation of inbound PAYEXT Idoc, the data has been transferred to in-house cash center to enable centralized payments to the bankers of external business partners. Assuming that correct configuration of IHC in FSCM component is set up in SPRO and relevant master records are available, the inbound PAYEXT Idoc would result in creation of payment orders. Screen shot below captures the payment order created against the inbound PAYEXT Idoc.

From the above screen shots, it is clear that payment order 34659 has been created through inbound Idoc 15088597 with status “Flagged for Posting”. Posting of payment order would result in creation of one outbound PAYEXT Idoc. This is essential for the creation of payment request to be subsequently processed through transaction F111 by the in-house cash center.

In the example quoted above, posting of payment order 34659 (Status – Finally Posted) results in generation of outbound PAYEXT Idoc 15088598. The outbound Idoc in turn would create an inbound PAYEXT Idoc 15088599 as it is loopback which essentially creates the payment request.




The inbound PAYEXT Idoc would result in creation of payment request which is then processed for payments. Inbound PAYEXT Idoc 15088599 ends up creating payment request 1074043.

The payment request is then processed through transaction F111 by the in-house cash center to remit monies to the bankers of external business partners.




Related Contents For more information, visit the Enterprise Resource Planning homepage. For more information, visit the Business Process Expert homepage.




Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this do cument, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the conte nt of this document.



SAP IDOC

Recommend Documents