In February and March 2012 the European Parliament and the Council of the European Union passed regulation 260/2012, establishing a deadline for the introduction of the Single Euro Payments Area (SEPA). SEPA applies to all national and cross-border Euro payments within and between the 32 member states of the European Union (EU), the three European Economic Area countries, and Switzerland.

The new regulation calls for the introduction of the new SEPA payment instruments by February 2014 (SEPA credit transfers) and November 2014 (SEPA direct debit). These payment instruments will gradually replace the currently existing domestic payment types such as DTAUS in Germany.

The imminent SEPA introduction was one of the main reasons that SAP introduced the new IDoc type PEXR2003. SAP users that have implemented SAP In-House Cash weren’t able to transmit the necessary SEPA information in the existing PEXR2002 IDoc format. SEPA credit transfer and direct debit payments need to contain a number of attributes to be accepted by a corporation’s house bank. Some of the most important attributes are:

• The mandate identification code
• The sequential type of the mandate (recurring or one-time debit)
• The mandate type (B2B or B2C)
• The creditor identifier

Without these attributes a bank in the SEPA zone wouldn’t be able to process a payment instruction. Besides SAP In-House Cash customers there is another use case for this new IDoc type. Some SAP users are directly exchanging IDocs with their house banks and would prefer to continue to use this service once SEPA is introduced.

SEPA Payment Types

Both the SEPA credit transfer and the SEPA direct debit (SDD) payment types are based on International Organization for Standardization (ISO) 20022 payment-processing standards and are defined as XML formats. The SEPA credit transfer does not differ significantly from the existing standard credit transfer within the EU, but it eliminates the current 50,000 Euro value limit. The SDD schemes are more complex payment instruments requiring the creditor to receive a mandate from the creditor’s debtors.

The mandate is the authorization and expression of consent that the debtor grants to the creditor allowing the collection of outstanding receivables from a specified debtor account. Creditors must store mandate information in their systems to prove the legitimacy of their collections and to transfer mandate-related data to their financial institutions. Both the SEPA credit transfer and the SDD payment instruments require the use of the international bank account number (IBAN). According to the new regulation the bank identifier code (BIC) is no longer needed after February 2014 for national payment transactions and after February 2016 for cross-border payment transactions.

Availability and Structure of the New PEXR2003 IDoc Type

The new IDoc type PEXR2003 was made available in 2010 and 2011 via a SAP_APPL Support Package in the SAP ERP releases 4.7, 5.0, 6.0 (enhancement packages 1 to 5). The SAP R/3 release 4.6C wasn’t supported anymore, which makes sense since official SAP support for R/3 ends in 2013 – one year before SEPA will be formally introduced. (See SAP note 1422928 for more details on the delivery of the Support Package.) Let’s quickly recall some IDoc basics before taking a closer look at the structure of the new IDoc type.

IDocs are a data format that is used for asynchronous Application Linking and Enabling (ALE) communication between logical SAP systems. ALE is also the technical basis for SAP In-House Cash, which usually requires connections with various other SAP systems inside a corporation. 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 of an IDoc contains a standard header consisting of a sequential segment number, a description of the segment type, and a 1,000-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.

Let’s have a closer look at the structure of this new IDoc type now. You can display IDoc types by following menu path Tools > ABAP Workbench > ALE > ALE Development > IDoc Types. The new basic type PEXR2003 is an extension of the previous PEXR2002 IDoc type. It includes all the data segments of PEXR2002 and all of the former data structures remain unchanged. What is interesting are the five new data segments on the top hierarchy level at the bottom of the PEXR2003 IDoc (Figure 1).

Figure 1

Overview of the PEXR2003 IDoc structure

The five data segments at the end of the IDoc type PEXR2003 have the following meanings:

1. E1IDIBA: This data segment contains the international bank account number (IBAN) and the bank identifier code (BIC) which is also referred to as the SWIFT code. SWIFT (Society for Worldwide Interbank Financial Telecommunication) is an international organization headquartered in Brussels that is involved in the standardization of financial transactions including the unique assignment of BICs to financial institutions.
2. E1IDS01: This data segment contains the relevant attributes of the direct debit mandate, which is required to process the new SEPA direct debit payment format.
3. E1IDAD1: This data segment includes the address data of the two parties that are involved in a payment transaction (the payment receiver, who is the creditor, and the payer, who is the debtor)
4. E1IDTRA: This data segment includes the transaction data that is being transmitted in the IDoc type, including the type of mandate.
5. E1IDDS1: This data segment can be used to store a digital signature that might be generated by the sender of the payment instruction.

You can display the details of these data segments by double-clicking them and clicking the Segment Editor button on the pop-up screen. You can also use transaction WE31 (see the details of the data segment E1IDS01 in Figure 2.

Figure 2

Details of the data segment E1IDS01

Let’s look more closely at the attributes of the various data segments and how they’re being used and populated in the SAP system. The data being used to populate the IDoc type PEXR2003 is the payment data stored in table REGUH following the payment run of transactions F110 and F111.

E1IDIBA

Data segment E1IDIBA is filled in sync with the PEXR2002 segment E1IDB02 (payment header), which is also present on the top level of the IDoc type. There are only three segment fields included in the data segment E1IDIBA: FIIQUALI (for the payer and the receiver of the payment), IBAN, and SWIFT Code. The values in the data segment E1IDB02 aren’t modified and are filled in the PEXR2003 in the same way as they were used for its predecessor. E1IDB02-FIIKONTO corresponds, for instance, to the IBAN field and E1IDB02-FIIBKENN corresponds to the SWIFT code.

There are only two possible qualifiers for FIIQUALI: BA, who is the initiator of the payment (which is generally the company code of the paying subsidiary) or BB, who is the payment receiver. In the case of a SEPA credit transfer it is the receiver, while in the case of a SEPA direct debit it would be the party authorizing the debit. The IBAN field is filled by the SAP system only if you have maintained this attribute in the master data. The segment is being created for the IDoc message types DIRDEB (direct debit) and PAYEXT (credit transfer).

E1IDS01

Data segment E1IDS01contains 26 fields from SAP’s mandate management component (see table SEPA_MANDATE). The segment can appear twice with the qualifier ACT (current mandate data) and the qualifier ORIG (original mandate data). The reason for this distinction is that the SEPA rules foresee so-called mandate amendments to record alterations of an existing mandate such as a new address or a new debit amount. The PEXR2003 shows the ACT-Segment first. If there is a second ORIG-segment, the SAP system fills the field E1IDS01-AMEND_IND with X. This segment is only created by the system for the IDoc type DIRDEB. A prerequisite would be that the payment run picks up a mandate (the field MGUID in the table REGUH is filled).

The data segment E1IDS01 with the qualifier ACT contains the following fields:

• QUALIFIER (possible are ACT or ORIG)
• MANDATE_ID (unique mandate reference identifier for the creditor)
• MANDATE_TYPE (B2B ore B2C)
• VAL_FROM_DATE and VAL_TO_DATE (validity of the mandate)
• SIGN_DATE and SIGN_CITY (date and location of the mandate signature)
• CREDITOR_ID (unique creditor identifier which is filled from the field SEPA_MANDATE-REC_CRDID)
• CREDITOR_NAME1 and CREDITOR_NAME2 (name of the creditor)
• ULTIMATE_CREDITOR_NAME and ULTIMATE_CREDITOR_ID (name and identifier for the original creditor in case of on-behalf payments)
• AMEND_IND (X if there is an ORIG-segment)
• AMENDMENT_REASON_CODE (reason for the mandate amendment which is currently not filled)
• B2B (for the B2B direct debit scheme – otherwise the SAP system would fill the field with CORE, which is the B2C mandate type)
• DEBTOR_NAME1 and DEBTOR_NAME2 (name of the debtor)
• DEBTOR_IDENTIFICATION (unique identifier of the debtor)
• LANGUAGE (language key)
• ULTIMATE_DEBTOR_NAME and ULTIMATE_DEBTOR_ID (name and identifier of the original debtor in case of on-behalf payments)
• CONTRACT_REFERENCE (reference identifier for the underlying contract of the mandate)
• DEBTOR_IBAN and DEBTOR_SWIFT (IBAN and SWIFT code from the mandate)
• CHANGE_DATE and CHANGE_TIME (time fields stored in the mandate)

The data segment with the qualifier ORIG contains the original mandate values before the amendment. The fields MANDATE_ID, CREDITOR_ID, DEBTOR_IBAN, DEBTOR_SWIFT, CREDITOR_NAME1, and CREDITOR_NAME2 are included in this segment. These values are transferred only once after the mandate changes have been applied.

E1IDAD1

This data segment contains 24 segment fields that are being used to transmit address data of both the debtor and the creditor from the mandate management. This data segment is only filled if the previous mandate segment E1IDS01 is filled. The data segment E1IDAD1 contains the following segment fields:

• QUALF (possible are the qualifier CRE for the creditor and the qualifier DET for the debtor).
• ANRED (title of the creditor and debtor which is currently not filled)
• NAME1 to NAME4 (for the name of the creditor coming from the fields SND_NAME and the name of the debtor coming from the field REC_NAME in table SEPA_MANDATE. NAME3 and NAME4 are currently empty, though)
• STREET1, STREET2, CITY1, CITY2, HAUSN, POSTAL_CODE, PSTL2, PFACH, PFORT, COUNTRY_KEY, REGIO, TELF1, TELFX (containing the address details of the creditor and the debtor). These fields are all populated from the data in the SEPA_MANDATE table (Figure 3). Some fields such as REGIO or TELFX aren’t filled, though. Use transaction SE10 to access the SEPA-MANDATE table.
• IDENTIFICATION_CODE (this is an optional code that is mutually agreed upon by the debtor and the creditor. The field remains empty for the moment.)
• FURTHER_IDENT_1 to FURTHER_IDENT_4 (additional optional identifier information)

Figure 3

Table SEPA_MANDATE

E1IDTRA

Data segment E1IDTRA contains only five segment fields, which carry the transactional data of the IDoc. The segment fields PURPOSE_CODE and CATEGORY_PURPOSE_CODE are currently empty and could transmit payment type information in the future. The segment field SEQ_TYPE can have four potential values:

• OOFF (one-time mandate which is not recurring)
• FRST (in case of a recurring mandate this value would represent the first usage)
• RCUR (this value would represent a recurring mandate)
• FNAL (this value would represent the last usage of a recurring mandate)

The data segment transfers two additional segment fields: END_TO_END_ID and INITIATING_PARTY. The first field will be filled with the number of the clearing document (REGUH-VBLNR) or in case of a human resources (HR) payment with the HR reference number. The second segment field could be different from the debtor or the creditor but would normally be filled with the creditor name (field T001-BUTXT). The segment fields END_TO_END_ID and INITIATING_PARTY will also be populated for the IDoc message type PAYEXT while all the other segment fields are only relevant for direct debit payments implying that they will only be filled for the DIRDEB message type.

E1IDDS1

Data segment E1IDDS1 could hold a digital IDoc signature (field DIGITAL_SIGNATURE), but it is currently not filled by the SAP system.

Further ALE Configuration

You are now familiar with the structure of the new IDoc type PEXR2003. If you want to use the PEXR2003 for your SAP IHC or SEPA project you need to do two things. First you have to configure the SEPA settings in the SAP system, which I described in my previous SAPexperts Financials articles. Second, you need to adapt the configuration of SAP IHC. Let’s have a quick look at what needs to be done there to replace the old PEXR2002 with the new PEXR2003. As you may remember 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 (previously PEXR2002) for payment orders from the various affiliates to the IHCC or the payment order from the IHCC to the clearing partner
• DIRDEB (previously PEXR2002) for direct payment orders from the various affiliates to 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 maintain 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.

The relevant SAP In-House Cash configuration that needs to be adapted is the partner profiles for communication between the logical SAP systems. Follow menu path Tools > ALE > ALE Administration > Runtime Settings > Partner Profiles or use transaction WE20. You need to make sure that the new IDoc type PEXR2003 is registered for the two IDoc message types DIRDEB and PAYEXT within the partner profile of the receiving bank. You can double-click the existing DIRDEB and PAYEXT nodes to display the current IDoc type (Figure 4).

Figure 4

Configuration of PEXR2003 IDoc type in the ALE partner profiles

If you haven’t registered the new IDoc type PEXR2003 in the partner profiles of the subsidiary bank the classic payment medium program RFFOEDI1, which is used during the payment run in the SAP system, will continue to generate IDoc message types using the old IDoc message type PEXR2002.

Juergen Weiss

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 Financial Supply Chain Management applications, including Electronic Bill Presentment and Payment, Dispute Management, Collections Management, Credit Management, Treasury and Risk Management, Bank Relationship Management, and In-House Cash as well as Accounts Payable and Receivable.

You may contact the author at juergen.weiss@sepa-now.de.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.