Payment Processing through IDOCs
Introduction to Electronic Payment Processing
Full electronic payment is an important aspect of electronic commerce. Companies today are moving away from paper checks and manual processing of wire and ACH payments to electronic payments. Almost all the banks today can accept electronic payment instructions from corporate clients. In addition to this, banks also allow for electronic payments for most payment methods such as wires, checks and ACH, as well as local payment methods in some countries. Payment Processing through IDOCs
One way to achieve this integration with banks would be to implement a custom solution by writing customized programs to create payment instructions and files which need to be sent to the banks. However, SAP has provided an easier way to implement this functionality by using an SAP IDoc interface. Most banks today allow for EDI payment processing through Payment IDOCs. SAP has capabilities to convert IDOCs into EDI message types or send the IDOCs directly to the bank through EDI medium electronically. Thus this option is gaining prominence today for SAP payment processing implementations.
IDOC-EDI Configuration
This section contains pointers to the configuration for IDOC-EDI payments.
Payment program configuration for IDOC-EDI payments
a. You must also configure the output of a printed summary sheet for each payment run;
b. Select the following forms in the field: FBZP – Paying Company Codes – In EDI Accompanying Sheet Form field – enter F110_EDI_01
c. In transaction FBZP – Pmt methods in company code – select the payment method in the company code you want – In the form data field: enter Next Form F110_EDI_01
d. You must also specify the variant as RFFOEDI1 in the payment methods configuration.
FBZP – Pmt methods in country – select the payment method in the country you want – assign the variant RFFOEDI1 in the payment medium program field
EDI-Compatible Payment Methods It is required that the payment program identifies payment methods with which house banks can be used for EDI, before the payments and bank collection can be carried out using EDI. In this step, we specify the supported EDI payment method for each EDI-capable house bank.
Financial Accounting – Accounts Receivable and Accounts Payable – Business Transactions – Outgoing Payments – Payment Media – EDI Payment Orders and Debit Memos – Define EDI-Compatible Payment Methods for a House Bank.
External Payment Method Configuration
The payment methods configured in SAP cannot be identified by the bank as to the type of payment that needs to be carried out for a given transaction. Hence banks expect the IDOCs to be populated with bank specific payment codes. This is done using external payment method Configuration.
Financial Accounting – Accounts Receivable and Accounts Payable – Business Transactions – Outgoing Payments – Payment Media – EDI Payment Orders and Debit Memos – Assign EDI Payment Method to External Payment Method. Payment Processing through IDOCs
The external payment method is the bank specific payment code which will be transmitted as an instruction for the type of payment to be carried out (e.g. check, ach etc) to the Bank through the IDOC.
Processing Remittance Advices through IDOCs
Current capabilities of SAP allow companies to transmit remittance advice details through IDOCs. As a result many banks provide additional functionality which allows the vendors to view the remittance information on the website once the IDOC has been processed by the bank and the payment has been made. This allows companies to do away with manual printing and processing of payment advice which results in reduction in costs and increased efficiency. Payment Processing through IDOCs.
The indicator commonly used to instruct the bank to display the remittance advice information online is configured as an instruction key in SAP configuration and assigned to the vendor in the vendor master. This setting allows companies to make this capability available for only those vendors who have a high transaction volume. This allows companies to keep their bank processing costs at a minimum. In order to instruct the bank to print online the remittance advice for a vendor payment, special instructions need to be configured in SAP. This is done using instruction key configuration which is country and payment method specific.
Financial Accounting – Accounts Receivable and Accounts Payable – Business Transactions –Outgoing Payments – Payment Media – Data Medium Exchange – Define Instruction Keys
For each of these instruction keys, instruction text and code word needs to be defined. These details will be provided by the bank with which the implementation team is dealing with.
Financial Accounting – Accounts Receivable and Accounts Payable – Business Transactions – Outgoing Payments – Payment Media – Data Medium Exchange – Define Instructions for Payment Transactions.
These instruction keys are then assigned in the vendor master for each of the vendors for whom this functionality needs to be activated.
Managing Localizations requirements:
Most countries have rules regarding the payment file formats, bank account numbers and other country specific mandatory data elements that need to be populated in the payment information that is processed by a third party. This information needs to be populated in the IDOC when the payments are generated in SAP. Standard SAP functionality provides for most of the common localizations that exist in different countries. However, care must be taken to match the data in these fields to the requirements provided by the banks. Payment Processing through IDOCs.
This is because often banks might place additional requirements with regards to what information they would like to see for the localizations in the IDOC. In cases where such information cannot be provided for by standard IDOC and bank master data set up, customization might be necessary. This can be achieved by using the user exit EXIT_SAPLIEDP_002 (for PAYEXT) to meet the requirements
IDOC structure
Understanding the payment IDOC structure is the key to a successful implementation. By comparing the
standard IDOC elements with the format required by the bank, the implementation team can identify the
customizations that are required for successful payment processing. Once IDOC is generated, the structure
can be accessed at transaction WE05.
IDOC are split into three main sections Control records – They contain all the information for technical
processing Data records – Contain the actual application data Status records – Keep the processing records
IDOC Control Record Structure.
The Control Record contains the administration information for technical processing, as well as the IDoc and message type. This information specifies the structure and the content of the next part. Only one control record is generated for one payment run while multiple data records can be generated for the same payment run.
You can also read for :-SAP PO for Beginners Part – 12 – Interface Development – B2B EDI Inbound to XML Proxy to ECC
IDOC Data Record Structure
Data records hold the transactional data which is used by the bank to make the payment. Each data record consists of multiple segments, each of which contains specific data related to the payment being made. This data needs to be populated based on the requirements given by the bank. Attached below are the important segments of the IDOC data record structure and the information populated in them by SAP. The fields commonly used by the banks have been highlighted. Depending on the requirements given by the bank, the standard SAP IDOC may have to be customized to produce the IDOC in the format required by the bank
Benefits of automated IDOC processing:
Following are some of the benefits of using this approach over manual or custom solution
a) Minimum technical development required.
b) Greater automation with straight through payment processing via most banks with minimum manual input can be achieved using this approach.
c) Multiple IDOCs can be grouped together as required which reduces payment processing costs.
d) Standardized format results in reduced time to integrate new countries, company codes and
payment methods into the existing EDI-IDOC interface.
e) Increased scalability for handling high payment volumes.
f) More accurate transfer of data and reduction in data-integration risk with the bank interface
g) Electronic Remittance Advice functionality supported which results in elimination of paper handling of remittance advice and reduced costs.
Variant in Payment Program
In order the IDOC to be generated, one important aspect is that program being used for the creation of IDOC – RFFOEDI1 should have a variant.
After the variant is created, the variant should include the payment method which requires the creation of IDOC and also the check box “generate the SAP IDOC” should be checked.
Bank Master data management
For the IDOC payment process to function successfully, there are three types of master data that needs to be created and managed appropriately:
- Bank directory
- House bank data
- Vendor bank data
Bank directory:
For every bank that will be used by House bank, Vendor master, Customer master or Business partners, the bank directory need to be defined. The bank directory constitutes several fields such as Bank key and SWIFT code. These fields may be required or optional depending upon country specific requirements. The following is the list of key data in the bank directory.
Country Code BANKS
Bank Key BNKA-BANKL
Bank Number BNKA-BNKLZ (and BNKA-BANKL, if the bank number is selected as the
bank key)
SWIFT BNKA-SWIFT (and BNKA-BANKL, if the bank number is selected
as the bank key)
Bank Name BNKA-BANKA
City BNKA-ORT01
Street BNKA-STRAS
Branch BNKA-BRNCH
There are several sources from where the bank directory data can be obtained. The following are three major sources:
Ready-to-load file provided by third parties (e.g. Thomson Financials)
BIC File: Country specific format
Legacy system bank data
There are several ways to load these bank data into SAP. The following are the loading options corresponding to the above three data sources:
- Ready-to-load file: T-code BAUP
- BIC file: T-code BIC
- Legacy data: LSMW through T-code FI01
House Bank Data:
Here we link the bank directory data of the house bank with two major components:
Account data:
Account number, account currency, control key, and corresponding GL account number against which cash transactions will be posted.
EDI Partner profiles:
For each bank with which we are setting up the payment processing interface, we need to create a partner profile in SAP. This is done using transaction WE20. To create a partner profile we need to enter the partner number and partner type as “bank” in this transaction. For this partner profile you would need to maintain message types that are determined by the bank. For example, Citibank recommends message types EUPEXR and PAYEXT.
You must set up outbound parameters for message types “PAYEXT” using IDoc type “PEXR2002” and for message type “EUPEXR” using IDoc type IDCREF01. For all message types output mode should be “4” (Collect IDocs / Do not start subsystem) and the segment release should be “45A” (field “Seg. Release in IDoc type”).
Once partner profiles are defined, it can be linked to the house bank. Additionally, the payment methods also need to be mapped to EDI partner profile at the house bank level for the automatic payment program to function. Payment Processing through IDOCs.
Vendor Bank Data
Once the bank directory for a vendor bank is loaded, it can be mapped to the corresponding vendor account number. In the vendor, customer or business partner master, the following data is mandatory:
- Bank country
- Bank key
- Account number
Depending upon the country requirements, additional fields such as Check digits and IBAN number may be mandatory. For example, in almost all west European countries and parts of the middle-east IBAN is mandatory.
Increasingly, a lot of countries are adapting IBAN for it virtually eliminates the possibility of payment error. IBAN contains all the key bank account details such as Bank Identifier Codes, branch codes, and account numbers. IBAN contains check digits which validates a given combination of country code, routing destination and account number. Hence, if the bank key or account number is wrong, the check digit will invalidate such IBAN, resulting in failure of payment processing at the source itself. For this reason, IBANs have reduced trans-national money transfer errors to under 0.1% of total payments. Payment Processing through IDOCs
In some situation, a vendor may have more than one bank account and depending upon the transaction/currency type, the payment may have to be made to corresponding account. In such case, Bank partner reference number has to be created. In the above figure, we have a partner reference identifier (BnkT field label) for each bank account. At the invoice level, one of these banks can be selected through this partner identifier so that payments will be made to the correct bank account.
Appendix Transactions Description.
FI01 Create Bank directory
FI12 House Bank account master
WE20 Maintain Partner profiles
WE21 Assign file ports to Partner profiles
XK01 Vendor master creation
FBZP Maintain Payment program
WE05 Access IDOC structure
