PAIN.002 – Payment Rejections processing via RFEBKA00
This blog post provides detailed information about the process of importing pain.002 with rejected incoming or outgoing payments using the standard report RFEBKA00 (transaction FF_5). It focuses on the technical aspects of the solution, rather than the customizing which is described in the prerequisite notes.
Pain.002 or payment status report is a log containing the actual status of payments (e. g. rejection, acceptance) submitted by SEPA Credit Transfer (pain.001) or SEPA Direct Debit (pain.008).
The diagram below shows a simplified process from invoice creation to reversal via a pain.002 status message.
Note: Step 4.a. is only executed when you receive the pain.002 file. If you don’t receive pain.002 file, there is no need for the reversal (step 4.a. is skipped), and the process finishes with the CAMT.053 upload.
Outgoing files that are sent to the bank must be generated from the SAP system. They must contain the information necessary for finding the correct payment document that is supposed to be reversed from the RFEBKA00 import of pain.002. What information and how it is used will be described below.
Only Rejected Items
As mentioned in the SAP note 2311257, using RFEBKA00 you are only able to process items of pain.002 with the status Rejected. That means there must be at least one item with such status.
Please note that RFEBKA00 only serves to reverse rejected payments. If you require to process all information from pain.002, you should use the Bank Communication Management solution where you get an overview of all payments and where you can update statuses from pain.002.
How the payment document to be reversed is found
The purpose of the functionality is to reverse the payment document that was posted during the payment run so that it can be processed again. The payment document is found based on the following information from pain.002:
- The tag <OrgnlMsgId> contains <MsgId> from the original payment file (pain.001 or pain.008) and this refers to the field REGUT-RENUM (Reference Number).
- The tag <OrgnlPmtInfId> contains <PmtInfId> from the original payment file and this represents a payment batch within the payment file. Later we will explain how exactly the system does the search.
- The tag <OrgnlEndToEndId> contains <EndToEndId> from the original payment file and it points to the payment document number posted during payment run. This payment document number is supposed to be reversed based on the rejection information in pain.002. The EndToEndId in the pain.001 and pain.008 is filled with the Internal reference from the Note to Payee (OBPM2) which is the payment document number.
- A prerequisite for this is that the payment documents are exported to the cluster table RFDT during the payment medium creation (export to RFDT is described in the next chapter). The export is done by calling the function modules DMEE_EXIT_SEPA_21, DMEE_EXIT_SEPA_31 and DMEE_EXIT_SEPA_41.
If the above prerequisites are fulfilled, the SAP system should have no problem finding the correct document to be reversed.
You can review the transformation in the transaction STRANS and test in the transaction XSLT_TOOL. You will see which fields from the pain.002 file are mapped into which internal FEB_S structure. Here is an example output that shows where each value is stored:
- EMKEY -> OrgnIMsgId
- VFDAT -> OrgnlPmtInfId
- WVDAT -> OrgnlEndToEndId
Export to RFDT for the pain.001 and pain.008
An important part of the end-to-end process is the export of payment documents into the table RFDT. Without exporting, it is impossible to find and reverse any of the payment documents (even if all the data from the payment file (pain.001/pain.008) are in the return file (pain.002)). This is a security measure to ensure that the processed pain.002 file is a reply for a payment file sent to the bank (identified by the Orgnl… tags).
Standard XML-based payment formats (CGI, SEPA_CT, …) call all three function modules:
If you are creating your own DMEE(X) tree and you want to make use of the pain.002 processing, you need to make sure that the function modules are called correctly only from one place:
- directly in the DMEE tree
- in the corresponding BAdI
- in event 05 of PMW via function module FI_PAYMEDIUM_DMEE_CGI_05.
Their combination could cause data inconsistency.
As an example, we can use the old DMEE tree SEPA_CT (please note that SEPA_CT has been replaced by CGI_XML_CT/CGI_CT but we use it as an example on how to call the mentioned FMs for a better understanding).
- DMEE_EXIT_SEPA_21 must be called on the payment batch level. In pain.001 structure this normally represents <PmtInfId>. It creates the so-called secondary RENUM. Collects all documents paid in one batch.
- DMEE_EXIT_SEPA_31 must be called on the transaction level. This function module appends the payment document to an internal table. It means it must be called for every payment in the batch.
- DMEE_EXIT_SEPA_41 must be called at the end of the file and just once. This function module exports the internal table with payment documents and batch IDs into the table RFDT.
Note: Make sure that the sorting keys and the levels in the DMEE tree are defined correctly to populate proper values. SAP formats define level 2 as Batch level and level 3 as Transaction level.
The above can be tested during the payment medium generation (tx FBPM) by placing the breakpoint into the function modules.
Test of pain.002 upload
Find more information about this solution and its customizing in SAP notes:
Do you have any further comments regarding this topic? Do not hesitate to share them in the comment section below. You are also welcome to ask any questions about SAP S4/HANA Finance in the Community Q&A section.