The Common Global Implementation Initiative (CGI) is a collection of banks, corporations, software vendors, and consultants that have come together to progress various corporate-to-bank implementation topics in the payments and reporting domain. The main objective is to create common global implementation templates for International Organization for Standardization (ISO) 20022 corporate-to-bank transactions. The CGI team focused on developing agreed-upon templates for six transactions:

• Customer Credit Transfer Initiation (pain.001.001.03)
• Customer Direct Debit (pain.008.001.02)
• Customer Payment Status Report (pain.002.001.03)
• Bank-To-Customer Statement (camt.053.001.02)
• Bank-To-Customer Account Report (camt.052.001.02)
• Bank-To-Customer Debit Credit Notification (camt.054.001.02)

Pain.001.001.03 and pain.002.001.03 are the XML messages that were developed by the CGI team. XML messages are documents consisting of tags and elements that adhere to an XML schema, which is a type of an XML document. Some elements are required for proper file structure, and some are required for identifying a business object or containing payment-related information.

From the payment standpoint in this article, we focus on pain.001.001.03 and pain.002.001.03 messages. The last two numbers (03) represent the version of the message. We focus on the structure of these two message types, the various tags used, and the possible values. We also focus on how these tags can be populated in the SAP system. 

Pain.001.001.03, of which the last two numbers represent the version of the message, is currently the most used version of the ISO 20022 credit transfer message and is the payment standard moving forward. Pain.002.001.03 is an acknowledgment file generated from a pain.001.001.03 payment file. SAP supports the pain.001.001.03 format after SAP Note 1665873 - DME XML Format as per ISO 20022 (CGI_XML_CT) has been applied to the system.

Pain.002.001.03 is an acknowledgment file generated for a pain.001.001.03 payment file. In other words, when a company sends a pain.001.001.03 payment file to the bank, the bank sends a pain.002.001.03 acknowledgment file back to the company. SAP supports importing the pain.002.001.03 status report in the SAP Bank Communication Management module.

The Structure and Key Tags Used in XML Payment Messages

The XML payment message is composed of three parts: group header, payment information, and credit transfer transaction information as shown in Figure 1.

Figure 1

Structure of an XML credit transfer message

There is one group header in the payment file. The information in the group header pertains to all payments in the file.

Payment information can be repetitive and contain information related to the paying (debit) side of the payment. This information can include, for example, payer, payer account, and payment type and execution date.

Credit transfer transaction information is part of the payment information section of the file. The credit transfer transaction information is mandatory and can be repetitive. It contains information related to the credit side of the transaction, such as the beneficiary, beneficiary account, and remittance information. The remittance information is optional. We now describe the key fields in each of these sections of the XML payment file.

Pain.001.001.03 (Payment Initiation Credit Transfer Message Version 3)

The different sections of pain.001.001.03 have several important tags. We describe these tags in this section.

Group Header

There is one group header in the payment file. The tag for the start of the group header is <GrpHdr>. The tag to close the group header is </GrpHdr>.

The group header contains a unique identifier for the payment file (message ID). The message ID needs to be unique for every file and can be used as a reference while communicating with banking partners.

The CreDtTm tag contains the file creation date and time.

The NbOfTxs tag contains the number of transactions (payments) in the file.

The CtrlSum tag contains the total amount of all payment amounts in the file. (The currency associated with this total amount is the currency of the account.)

The InitgPty tag contains the information such as name of the initiating part (SAP company code name), customer ID (the customer identification number used by the bank and typically maintained in the SAP house bank customer number field), and a constant (BANK), if requested by the bank. The value BANK is maintained in the SAP DMEE (Data Medium Exchange Engine) tree itself and it can be included or excluded from the output file using conditions based on the bank Bank Identification Code (BIC) or SWIFT code. Figure 2 is an example of the XML code for the group header for pain.001.001.03.

Figure 2

A sample group header

Payment Information

In the payment information section for pain.001.001.03, the tag for the first batch group is <PmtInf>. There may be multiple payment information groups in the file.

The PmtInfId tag contains a message ID that is the unique identifier for this batch of payments.

The PmtMtd tag contains the payment method type. The possible values are TRF (electronic transfer) and CHK (check). The value for this tag is determined from the payment method of the payment. If the payment method is configured as check, then CHK is populated; otherwise, the value is TRF.

The NbOfTxs tag contains the number of transactions (payments) in the file creation date and Time.

The CtrlSum tag contains the total of all payment amounts in the batch. Figure 3 shows the XML code for the payment information section of pain.001.001.03.

Figure 3

XML code for payment information for pain.001.001.03

PmtTpInf (Payment Type Information)

The payment type information segment contains information used to further specify the type of transaction. This information is about instruction priority and service level. Figure 4 shows the payment type information for an urgent payment (a wire), and Figure 5 shows the payment type information for a non-urgent payment. The <InstrPrty> tag is an indicator of the urgency of the order of importance the instructing party (sending party) wants to apply to the processing of the instruction.

Figure 4

Payment type information for an urgent payment

Figure 5

Payment type information for a non-urgent payment

In the InstrPrty (instruction priority) tag, the possible values are either HIGH or NORM. In most cases, the NORM value is used. To maintain these values in the SAP system, execute transaction code DMEE and complete the DMEE tree mapping in the form of atoms used to populate one value versus the other.

The SvcLvl (service level) tag is used to identify or communicate the rules or agreement under which the payment is processed. The content of this field varies depending on the payment type and the requirements specific to a region or bank. Table 1 shows some of the values pre-delivered by SAP. This tag is derived using conditions based on payment methods in the SAP system described in the “Configuration Steps to Create an XML File for Accounts Payable and Treasury Payments” section.

The LclInstrm (local instrument code) tag contains the value that complements the value provided in the service level tag. For example, if the service level tag contains NURG, this tag could contain PPD, CCD, or CTX for USD ACH payments in the United States, which provides further details about the kind of ACH payment. Table 2 shows some of the values pre-delivered by SAP.

In the SAP system, this tag is populated based on the payment method, payment method supplements, or instruction keys.

The CtgyPurp (category purpose) tag usually contains the reason for the payment. Table 3 lists some of the values pre-delivered by SAP.

In the SAP system, this tag is populated on payment method supplements or instruction keys.

The ReqdExctnDt (requested execution date) tag contains the value date for the payment (Figure 6). This is the date the initiating party requests that the clearing agent process the payment.

Figure 6

Payment value date

The value for this tag in the SAP system comes from the SAP payment document value date field.

The Dbtr (debtor) tag contains payer information such as name, address, and country of residence. Information for these tags is derived from company code and payment program configuration (Figure 7).

Figure 7

Debtor or paying company code information

The DbtrAcct (debtor account) tag contains the debit bank account number from the paying company code.  It contains either the bank account number or the International Bank Account Number (IBAN), but not both. It can also contain the currency of the bank account. The information in these elements or tags comes from the house bank account configuration (transaction code FI12). An example of a DbtrAcct tag is shown in Figure 8.

Figure 8

Payer bank account number

The DbtrAgt (debtor agent) tag contains the paying company code bank account-related information. It contains the local clearing code, SWIFT code, address, and branch ID. The information in these elements or tags comes from configuration completed after executing transaction code FI12 and transaction code FI03 bank master data (Figure 9).

Figure 9

Payer bank information

The CdtTrfTxInf (credit transfer transaction information) tag contains the payment ID, amount per payment, charge code, creditor agent, creditor, creditor account, and remittance-related information. If an XML file contains multiple payments, it has multiple CdtTrfTxInf segments as well—one tag for each payment. Figure 10 is an example of an XML file that contains two payments that are debiting the same account.

Figure 10

Credit transfer transaction information

The PmtId (payment ID) tag contains the payment document identifier (Figure 11). The length of this tag is 14 digits, and we recommend that you use a combination of company code and payment document number in this field, which would uniquely identify the payment in the SAP system. It can also be used for correspondence with the bank for identifying and troubleshooting any issue with the payment as it is a unique identifier for the payment. The InstrId and EndtoEndId are also reported in the pain.002 message that you receive from your banking partner. The information with the EndtoEndId is included in the bank statement when the payment clears the bank.

Figure 11

Payment identifier

As mentioned, we recommend using a combination of a company code and a payment document number as the end-to-end ID.

The InstdAmt (instructed amount) tag contains the payment currency and amount (Figure 12).

Figure 12

Payment currency and amount

The value for this tag comes from the payment document amount and currency.

The ChrgBr (charge code) tag contains the charge code, which specifies which party or parties bear the transaction code.  (The transaction cost is the payment processing fee charged by the banks.) Table 4 lists the four possible charge code values.

In the SAP system, these values can be maintained in the DMEE tree itself, and they are populated in the output file using conditions. Alternatively, this tag can be driven by another field, such as the cost allocation key defined in the instruction key on the payment. Charge code SHAR (shared) is used in Figure 13, indicating a credit transfer. The transaction costs on the sending side are borne by the debtor (payer), and the transaction costs on the receiver side are borne by the creditor (beneficiary).

Figure 13

Charge code shared

The CdtrAgt (creditor agent) tags contain the vendor or beneficiary bank-related information. This information comes from the bank master data record (transaction code FI03/table BNKA) using the bank country and bank key that are maintained in the beneficiary master data (Figure 14).

Figure 14

Payee bank information

Figure 15

Payee information

The CdtrAcct (creditor account) tag contains the vendor bank account number and name of the bank account holder (Figure 16). If an IBAN is maintained in the vendor master data, it takes precedence over the bank account number. Other pieces of information, such as account type (checking, saving, cash, or loan), are also captured in this segment, provided that they are maintained in the vendor master.

Figure 16

Payee bank account number

The RmtInf (remittance information) tag is optional. There are two different segments in an XML file that can contain this information—unstructured (Ustrd) and structured (Strd). In Figure 17 you see an example of how unstructured remittance data can be specified.

Figure 17

Remittance information

What type of remittance information you use depends on your banking partner and its ability to pass the information on to the beneficiary. Most banks allow up to 140 characters per payment. In an unstructured remittance tag, the information about all the invoices is captured in the same line as shown in Figure 17.

The Strd (structured) tag contains the information such as invoice date, reference number, amount, and reference text in a structured format that can be passed on to the beneficiary by the bank. Figure 18 is an example of a structured remittance tag. In an XML message, you have as many structured remittance tags as the number of the invoices or documents in the payment. For example, if a payment is made for five invoices, there are five structured remittance tags and each contains the details of one invoice.

Figure 18

An example of structured remittance information

The Tp (type of document) tag (Figure 19) indicates the type of document being referenced. Examples are invoice, credit notes, and credit memos.

Figure 19

An example of a document type tag

The most commonly used values in the SAP system are CINV (commercial invoice) and CREN (credit memo or note).

The Nb (number) tag contains the invoice number. In the SAP system, the value for this comes from the reference field of an SAP invoice document. The RltdDt (related date) tag contains the invoice date. In the SAP system, the value for this comes from the document date from an SAP invoice document (Figure 20).

Figure 20

Invoice and related date

The DuePyblAmt (due payable amount) tag contains the gross invoice amount. The RmtdAmt (remitted amount) tag contains the net payment amount (Figure 21). The value for both of these tags comes from an SAP invoice document. If taxes and discounts are involved, then the tax and discount tags are populated as well. The sum of the remitted amounts must be equal to the instructed amount.

Figure 21

Remitted currency and amount

The AddtlRmtInf (additional remittance information) tag contains information about the invoice in a free text form, as shown in Figure 22. The information in the tag in the SAP system comes from the line-item text of an SAP invoice document.

Figure 22

Additional remittance information

Pain.002.001.03 (Customer Status Payment Report Version 3) and the Relationship between Pain.001.001.03 and Pain.002.001.03 Messages

When you send a pain.001.001.03 message to your banking partner, you receive a pain.002.001.03 formatted message from the banking partner. A pain.002.001.03 message is a status report (acknowledgment file) that provides the processing status of the transactions that were sent in the pain.001.001.03 file. You might receive more than one pain.002.001.03 message for a given pain.001.001.03 file, and the number of pain.002 files received for a given pain.001 file depends on the nature of the transactions and the ability of your business partner (bank).

GrpHdr (Group Header)

Figure 23 is an example of XML code for a pain.002.001.03 message group header.

Figure 23

A group header

The MsgId (message ID) tag contains the unique identifier for the message and can be used as a reference while communicating with your business partner.

The CreDtTm (create and time) tag contains the message creation date and time.

The BICOrBEI (BIC [bank identification code] or BEI [business entity identifier]) tag contains the information about the sender of the message.

If the message is sent by a bank, then the tag contains a BIC. In all other cases, the tag contains a BEI.

The OrgnlGrpInfAndSt (Original Group Information and Status) tag contains the original pain.001.001.03 file details, such as message ID, type of message, original message creation date and time, number of transactions, and payment amount.

When you upload or import a pain.002.001.03 message in the SAP system, the OrgnIGrpInfAndSts (original group information and status) tags are used to map the pain.002.001.03 message with the pain.001.001.03 message (Figure 24).

Figure 24

Original group information and status

The OrgnlPmtInfAndSts (original payment information and status) tag contains the payment information that was sent in the pain.001.001.03 message and corresponding status. In Figure 25, one payment is sent in the original file.

Figure 25

Original payment information and status

The OrgnlEndToEndId (original end-to-end ID) tag contains the payment identifier. Once the pain.001.001.03 message is identified, an end-to-end ID is used to identify the payment in that message file.

The TxSts (transaction status) tag contains the payment status (Figure 26).

Figure 26

Transaction status tag

The code provided in this tag must be set up in the SAP system for the successful upload of a pain.002.001.03 message and the status update for the payment. It is important to mention the upload of pain.002.001.03, and the status update is only possible if the client is using SAP Bank Communication Management.

Table 5 lists some of the possible values for tag transaction status.

The StsRsnInf (status reason information) tag contains some additional information about the transaction and includes some free-form text (Figure 27).

Figure 27

Status reason information

The AcctSvcrRef (account service reference) tag contains the reference information that is assigned to the payment transaction by the bank to unambiguously identify each payment. This information can be used as a reference while communicating with the bank for a specific transaction (Figure 28).

Figure 28

Account service reference

The OrgnlTxRef (original transaction reference) tag contains information about the original message, and in most cases, this segment content comes from the pain.001.001.03 message file that we described earlier (Figure 29).

Figure 29

Original transaction reference tag

Overview of the Data Medium Exchange (DME) and Payment Tree

Now that we have given an overview of ISO XML messages and the important tags, we move into the functionality in the SAP system to support ISO XML payment messages.

There are two ways to define a payment method’s payment medium in the SAP system. One way is by using the RFF* payment programs, which are referred to as classic payment program payment methods. Another way of creating payment methods is using the payment medium workbench (PMW). The type of payment medium is specified at the definition of the payment method as shown in Figure 30, which is the payment medium section of the Define Payment Method in Country configuration (transaction code FBZP).  

Figure 30

Classic payment medium specification for a payment method

SAP Bank Communication Management is intended to be used with PMW payments. In other words, the payment method used for payments routed to SAP Bank Communication Management should be defined as PMW payments.

The DMEE is a graphical editor to design file formats. The DMEE can be used to generate outgoing payment files or convert incoming files that are then processed by the SAP system. The main advantage of the DMEE is that new file formats can be defined and maintained without significant ABAP programming.

The PMW and the DMEE are tools in the SAP system to make XML payments. The PMW is used to configure payment media (payment files) in the SAP system. SAP comes delivered with predefined XML format trees that can be copied and adjusted to create custom versions for the formats. The payment file is created by Accounts Payable (AP) or SAP Treasury and Risk Management payment programs and then delivered to the bank in file format. Figure 31 shows the steps involved in the AP and SAP Treasury and Risk Management payment process in the SAP system.

Figure 31

The payment process

Configuration Steps to Create an XML File for Accounts Payable and Treasury Payments

Now that you have an understanding of the structure of the XML payment format, we explain how to create a new XML tree, create a new PMW format, and assign this new PMW format to a payment method.

Before starting with these steps, ensure SAP Note 1665873 (DME XML Format as per ISO 20022 (CGI_XML_CT)) has been applied to your system. SAP Note 2056456 is also helpful for this process. SAP Note 2056456 is a collective note for CGI formats as per ISO20022.

Often on implementations, the decision of when to create a new payment tree is considered. For example, should a separate payment tree be created for each bank or for each geographical region? We recommend using as few payment trees as possible to minimize the ongoing maintenance of the trees. Before creating a payment tree, you should know what the strategy will be for when to create new trees (e.g., one per bank). Obviously, by using a global payment standard format, the need for multiple payment trees in the SAP system is significantly reduced.

Prior to implementing XML payments in the SAP system, you should have documentation from the banks to which the payments will be sent outlining how the XML file should be formed as variations from the standard are possible.

The main advantage of the CGI message type format is that it was designed to incorporate global payment requirements. This format can be used across countries and banks with minor variations based on specific country or bank requirements. Because it is a global format, you copy from the SAP-delivered CGI XML credit transfer message type.

Step 1: The best way to create a new format is to find an SAP-delivered format that is close to the one you want to create, copy from that XML format, and then make any necessary modifications to your custom format. A standard SAP system is delivered with many defined trees. From the DMEE, copy an SAP-delivered tree to create a custom tree. You can then modify this tree to meet your company’s needs. As mentioned above, you use the SAP standard CGI XML format for outgoing payments, which is CGI_XML_CT.

To create a new format, execute transaction code DMEE or follow menu path Financials > Financial Accounting (FI) > Accounts Payable > FI Accounts Receivable and Accounts Payable > Payments > Executing the Payment Program > Payment Medium Workbench > Data Medium Exchange Engine. In the screen that appears (Figure 32), enter PAYM (the data medium exchange for the payment program) in the Tree type field and CGI_XML_CT in the Format tree field. Click the copy icon .

Figure 32

Create a new format in the DMEE

After you click the copy button, you see a pop-up screen (Figure 33). Enter a name that starts with a z for your new XML format tree in the Format tree field in the Target format tree section and click the Copy button.

Figure 33

Copy the new XML format tree from the SAP tree to the custom tree

After you click the Copy button in Figure 33, you see a pop-up window (not shown) in which you enter a transport to be used for your new tree. Enter the workbench transport number to be used and click the enter icon . The following message appears in the screen indicating that your format tree was copied successfully: DMEE format tree CGI_XML_CT was copied to ZCGI_XML_CT_SAP_EXPERTS.

Using the DMEE, you have completed the message structure and the mapping of fields in the SAP system. Now we look at the details of the custom format tree.

In the initial screen for the DMEE (Figure 32), enter PAYM in the Tree type field and enter your new XML tree in the Format tree field. After you click the Change button, the screen shown in Figure 34 appears.

Figure 34

Edit the XML format tree

Enter a description for your tree in the Short Description field in Figure 34. The screen is divided into three sections. The left section of the screen shows the definition of the payment tree. After you click on a specific node in the section on the left, the upper right section of the screen defines the specific node. The lower right section of the screen shows the different SAP fields that are available when building the tree (Figure 35).

Figure 35

Structure of the XML credit transfer message

The left section of the screen shown in Figure 35 displays the different sections of the XML message. By opening up each of the nodes of the tree, you can see the definition of each of the fields.

When PMW is used, the structures FPAYH, FPAYHX, and FPAYP are populated with payment data as the payment medium creation step is run. (Refer back to Figure 31 on the steps in the payment process.) As mentioned, the lower right section of the screen shows the different SAP fields that are available in the data mapping process. The majority of the fields used when creating the output file are in the FPAYH, FPAYHX, FPAYP, and DMEE_PAYD structures, although other tables, structures, and fields are also available. The data in the FPAY* tables is populated from the REGUH, REGUP, T001, and BNKA tables for the most part.

Select the DMEE tree: properties line in the tree layout on the left side of the screen, and on the right side, click the Levels tab to view the number of possible occurrences of each level within the file (Figure 36).

Figure 36

Format tree properties

Level 1, which is the group header, occurs just once within each file. Each of the other levels can occur an unlimited number of times. Figure 37 shows the different levels for each of the main nodes of the XML payment file.

Figure 37

Level assignments

In the File Data tab (Figure 38), the characters that are not allowed to be in the file are listed. You can also enter your own format-specific characters that you wish to allow in or exclude from the file. You enter them one after another, with no spaces between them, and then select one of the radio buttons to exclude or allow the defined characters.

Figure 38

Excluding characters from file output

SAP provides a number of different mapping rules that can be used, as shown in Figure 39. You see these mapping rules assigned to each of the tree nodes when selecting the node in the left panel. Next, we walk through a few examples of these mapping rules.

Figure 39

Various supported mapping rules

The tree is defined by various types of nodes. Table 6 outlines the different node types. You can see the characteristics of each node by double-clicking the node on the left side of the screen, at which time the node displays a blue arrow  . The characteristics of the node are then displayed on the upper right side of the panel.

Node	Description
	This symbol is used to group segments.
	This symbol represents a node that is output to the target file.
	This symbol is used to group elements.
	This symbol represents one line of output to the target file. This can be a value or it can be used to group elements as subnodes.
	This symbol represents a link from the file definition to the internal SAP structures. A condition is used here, meaning that more than one value could be output to one element. The output is conditional on other elements.
	This is an element that is not output to the target file, but stores values that are used in other tree nodes (e.g., elements or atoms) by a reference to this node.

Mapping Procedure – Constant

Use the constant mapping procedure if the value to be output to the XML file is a constant value.  An example of when to use constant mapping in the CGI XML tree is for the charges indicator (tag <ChrgBr>) as shown in Figure 40.  In the Attributes tab, enter a name (e.g., SHAR) in the Name field and select a type (e.g., C Character) from the list of options. The Conv. function field controls the format of the field and is specified from a list of options. (The Constant radio button is the default mapping procedure.) Click the save icon after making your updates.

Figure 40

Charges indicator attributes

If you click the Source tab, you see the constant value to be output to the file SHAR, which means the charge for the payment will be split between the payer and beneficiary (Figure 41).

Figure 41

Charges indicator source

If you select the Conditions tab, you can see that the charges indicator is based on the setting of the cost allocation key, which is in FPAYHX-DTKVS (Figure 42).

Figure 42

Charges indicator attributes

When a file is generated from one of the predefined applications, the system processes the format tree and checks each node for conditions. If a condition is met, the system processes the node; if it is not, the node is ignored.

Based on the setting of the cost allocation key, the charges indicator will be output as CRED (FPAYHX-DTKVS = 02), DEBT (FPAYHX-DTKVS = 01) or SHAR (FPAYHX-DTKVS = 00).

Mapping Procedure – Structure Field

Use the structure field mapping procedure if the value to be output to the XML file is to be based on a specific source field in the SAP system.

As mentioned previously, when PMW is used, the structures FPAYH, FPAYHX, and FPAYP are populated with payment data as the payment medium creation step is run. The lower right section of the screen shows the different SAP fields that are available in the data mapping process (Figure 35).

Figure 43 shows the attributes of the instructed amount field <InstdAmt> tag). Note that the mapping procedure is set to Structure field, meaning the value for this field will be retrieved from a specific source field on SAP.

Figure 43

Attributes of the instructed amount field

Click the Source tab of the instructed amount field <InstdAmt> tag (Figure 44). In the Mapping from structure field section, enter FPAYH in the Structure field and RWBTR in the Field name field. These names are for the amount paid in transaction currency.

Figure 44

The Source tab of the instructed amount field

Mapping Procedure – Aggregation

The DMEE offers a number of special functions, such as aggregation. In aggregation, a value related to a reference node is totaled and made available to a different node. In the group header, there are two field values that are determined using aggregation. They are the number of transactions (<NbOfTxs> tag) and the control sum (<CtrlSum> tag). Figure 45 shows both of these fields in the group header.

Figure 45

Fields in the group header

The control sum field is an aggregation field as shown in Figure 46.

Figure 46

Attributes of the instructed amount field

The Aggregation tab of Figure 47 shows that the CtrlSum field is a sum of the values of the IA field, which is the instructed amount field described above. In other words, if you look at Figure 44, you see that the instructed amount field, which is the amount of the payment, has a reference ID of IA. The CtrlSum field is an aggregation (a summation) of all the instructed amount fields (payment amount) in the file. The aggregation function enables the CtrlSum tag to contain the total amount of all payment amounts in the file.

Figure 47

The Aggregation tab of the instructed amount field

Figure 48 shows the Attributes tab of the number of transactions (tag <NbOfTxs>) field.

Figure 48

Attributes of the number of transactions field

Note that the number of transactions is an aggregation of the number of occurrences of the <CdtTrfTxInf> tag in the file, as shown in Figure 49. For more information on the <CdtTrfTxInf> tag, see the explanation of this tag in the “Payment Information” section.

Figure 49

The Aggregation tab of the number of transactions field

Making Changes to the DME Tree

To change the charges indicator tag to be SHAR (shared) for all payments, go to the <ChrgBr> tag in the left panel of the DMEE (Figure 50).

Figure 50

The charges indicator node

Select the CRED atom and click the delete icon . Select the DEBT atom and click the delete icon.  Now you are left with just the SHAR atom. You want to delete the condition on the SHAR atom because now you want SHAR to be the output for this tag for all payments. Select the Conditions tab, place your cursor on the condition, and click the delete row icon  as shown in Figure 51.

Figure 51

Delete condition

When you are done with any edits to the DME tree, click the check icon  to check the XML tree for errors. You see the message shown in Figure 52.

Figure 52

Check function successful

The XML tree must be activated before you can use it. To activate the XML tree, click the activate icon . After you click the activate icon, you are prompted to put the DME tree into a workbench transport. You should see the following message in your screen: Format tree activated.

Now that the XML tree is created, you can assign it to a payment medium format and then to a payment method. We go through the mandatory configuration steps to produce the XML payment file. The configuration steps here are not a comprehensive list of configuration steps as this article focuses primarily on the CGI XML structure and how that specifically can be done in the SAP system.

Execute transaction code OBPM1 or follow IMG menu path Financial Accounting (New) > Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments > Automatic Outgoing Payments > Payment Media > Make Settings for Payment Medium Formats from Payment Medium Workbench > Create Payment Medium Formats. In the initial screen (not shown), click the New Entries button. In the Format field of the next screen (Figure 53), enter the same name as the XML tree just created.

Figure 53

Create a payment medium format

Select the Payment medium without docs. indicator and specify that the new format is to generate an XML file by selecting 04 XML from the drop-down list of options in the Type field. The Extra list for payment medium and Payment medium accompanying sheet indicators should only be selected if a payment advice should be created for payments. In the Struct. for format parameters field, enter FPM_PAYD and 10 in the No. of digits field. Select the Mapping using DME engine indicator.

The indicators in the Payment medium output divided by level of detail section specify at what level the payment files should be created.  For example, if you want payment files created by company code and house bank, use the settings shown in Figure 53.

After completing the above changes, click the save icon. If you see the following message: Choose the key from the allowed namespace (not shown), click Enter through the warning message. (As mentioned, your DME tree and the payment medium format should have the same name and it should start with a z.) You are then prompted to enter a workbench transport to be used for the configuration changes as shown in Figure 54.

Figure 54

Prompt for a workbench transport

When you use the PMW, one program, SAPFPAYM_SCHEDULE, is used to create the payment media. The AP and Treasury and Risk Management payment programs trigger the program SAPFPAYM_SCHEDULE to run at the create payment medium step, which creates the payment media (payment file). After the configuration for the payment method has been done, the variants can be created. The variants to be used when SAPFPAYM_SCHEDULE is run are assigned in configuration. Before the variants can be assigned in configuration, the variants must first be defined. To complete this step, execute transaction code SE38, and in the screen that appears, enter the name SAPFPAYM in the Program field as shown in Figure 55. Note that you must create the variants on each system.

Figure 55

Execute the SAP Payment Medium Creation Program

Click the execute icon .  You are then taken to the screen shown in Figure 56. (Note: Transaction code FBPM will take you directly to the Payment Medium: Creation screen for SAPFPAYM.) 

Figure 56

Create the payment medium creation variant

By clicking the Format parameters and Print parameters, you can enter format-specific and print-specific parameters, respectively.  In the Payment Medium Format field, enter the payment medium format created in the step above, and then press Enter. 

Under the Print Control section, select only the Data Medium Exchange and Error Log indicators, as we are not printing payment summary and we want to output the error log.  

In the Output Control section, enter the directory and file name of the payment file.  Select the Payment Document Validation to ensure any payment documents sent in the payment file are valid. 

Click the save icon to save your changes.

The next step is to assign the variants in configuration. Execute transaction code OBPM4 or follow IMG menu path Financial Accounting (New) > Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments > Automatic Outgoing Payments > Payment Media > Make Settings for Payment Medium Formats from Payment Medium Workbench > Create /Assign Selection Variants. Double-click the new payment medium format just created on the left of the screen (not shown). On the right of the screen, you assign the variant, as shown in Figure 57.  

Figure 57

Assign the payment medium creation variant

Note
To save the variant assignment to a transport, you must select the tab to the left of the entry () for each entry that has a variant assignment and click the transport icon .  You are then prompted to enter a workbench transport (not shown).

Next, assign the new PMW format to a payment method. Execute transaction code FBZP or follow IMG menu path Financial Accounting (New) > Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments > Automatic Outgoing Payments > Payment Method / Bank Selection > for Payment Program > Set Up Payment Methods per Country for Payment Transactions. In the Payment Medium section of the screen that appears, select the Use payment medium workbench indicator and enter the newly created payment medium format in the Format field (Figure 58).

Figure 58

Assign the PMW format to a payment method

After you create the XML tree and assign the format to a payment method, you can run the AP or Treasury and Risk Management payment program.

For our example, run the AP payment program by executing transaction code F110 or following the menu path Accounting > Financial Accounting > Accounts Payable > Periodic Processing > Payments. Figure 59 shows the AP payment program run. 

Figure 59

AP payment program run

The payment programs (F110 and F111) automatically show the Create payment medium indicator if the payment run involves payment methods with a PMW format (Figure 60).  You must select this indicator to create the payment files. 

Figure 60

The Create payment medium indicator at the schedule payment step

Figure 61 shows the payment log from our AP payment run. To access this log, click the Payment button (Figure 59). Note the references in the payment log indicating the payment medium format and XML file created.

Figure 61

AP payment run log

To view the XML file created, execute transaction code F110 and follow menu path Environment > Payment Medium > DME Administration. Alternatively, you can execute transaction code FDTA to get to the DME (Data Medium Exchange) Administration screen.  Enter a date in the Run Date field and the name of your payment run in the Identification field. Click the execute icon to run the program (Figure 62).

Figure 62

Enter a run date and an ID name in the Data Medium Administration screen

You are then taken to the Data Medium Overview screen (Figure 63). Select the tab to the left of the payment run and click the display icon  to view the XML payment file.

Figure 63

Select an XML file

If you do not see a row for your payment file in FDTA and the payment run completed successfully, you did not get an XML file. You may want to check for failed jobs using transaction code SM37. (As mentioned, the payment programs create a job that creates the payment medium. You see this when looking for scheduled jobs after executing transaction code SM37.)

To view the XML file, click the display icon. This action opens a screen that shows the XML file (Figure 64).

Figure 64

View the XML file

Refer to following SAP Notes for more implementation details.

1665873 - DME XML Format as per ISO 20022 (CGI_XML_CT)

2056456 – Collective note for CGI formats per ISO20022 specifications

1722824 – BNK: Upload pain.002.001.03

1803299 - BNK: XSLT for PAIN.002.001.03   

1062489 - Documentation on the PMW

1127555 – PMW XML Files (SEPA): Encoding in Header Incorrect

Mary Loughran

Mary Loughran has been specializing in the SAP Financials area since 1997 and has worked with numerous clients throughout North America and Europe in the areas of finance and treasury. She was employed as a consultant with SAP America and was a designated expert within SAP America for treasury before she left SAP in 2004. Mary’s expertise is in the areas of SAP Treasury and Risk Management, SAP In-House Cash, Liquidity Planner, Accounts Payable, payments from SAP in general, Cash Management, and Electronic Banking. Mary was an independent consultant from 2004 to 2016. 

You may contact the author at loughran@gmail.com.

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

Praveen Gupta

Praveen Gupta has been specializing in the SAP Financials area since 2005 and has worked on numerous projects in the areas of finance, treasury, legal, and product management. Praveen’s expertise is in the areas of treasury and risk management, accounts payable, electronic banking, cash management, payments and SWIFT. Since 2014, Praveen has been a consultant with e5 Solutions Group.

You may contact the author at praveen.gupta@e5solutions.com.

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