Creating payments in SAP Treasury based on proprietary formats using PI
A typical implementation of SAP Treasury implies that payments that used to be processed de-centrally are now managed in the In-House Bank. To minimize the impact for the local units and thus gain acceptance, the Treasury department may decide to support the formats that these business units used to generate with their local applications.
In this blog I would like to share my experiences mapping different payment formats using SAP PI.
First of all you need to know how the payment order is going to enter the SAP Treasury system. Basically there are 2 options: Idoc PEXR2002 or the Enterprise Service (XML) CollectivePaymentOrderCreate. The payment orders will be delivered to the SAP Treasury system from SAP (R/3 or ECC) systems or from non-SAP systems. In SAP to SAP communication the Idoc will be the most logical choice. It has been around from early releases and most SAP companies are familiar with it. One could argue that a proxy to proxy scenario is feasible for newer releases, but in my opinion the error identification and resolution is much more mature with idocs.
In a typical scenario both SAP and nonSAP systems may deliver payments to SAP Treasury. In that case it makes sense to map the messages in proprietary formats to the PEXR2002 idocs. Formats I have come across during my work include the Dutch BTL91 and Clieop03 format, the Swedish SISU and BGC format, DTAus and DTZ from Germany, DTACH from Switzerland and others. These payment formats are all flat files with either a fixed record length or have records with a key field.
The basic interface design for this kind of flow is that the PI file adapter picks up the file from a folder, applies content conversion and maps the converted xml to the PEXR2002 format. The big bulk of the work here is to find out what the exact layout is of the flat file to be sure you cover all options. Different sources exist for the description of these files. My 2 favorites are:
1) The internet. Banks and financial institutions often publish format descriptions on their web site. Here are some sample links for the formats I mentioned before.
2) SAP. In the Payment Medium Workbench most of the external formats already exist for outbound processing. The data types can be used for identifying field descriptions and field properties as shown in the screenshots.
Drop down list for Format tree
Layout of the BTL91 format
Hopefully this blog was helpful to you when designing payment related interfaces.
In my next blog I will describe some of the challenges that came with the specific formats. These include the splitting of payments, no carriage return/linefeed in the source file and the identification of the sender system.