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.
The necessary customizing for this solution is described in the prerequisite notes 1957980 and 2311257.
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.
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:
If the above prerequisites are fulfilled, the SAP system should have no problem finding the correct document to be reversed.
The program logic consists of two main parts – a BADI and a transformation. These can be customized in the activity Define Mapping Procedure (under Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Electronic Bank Statement > Country/Region-Specific Settings > XML Format and Bank-Specific Formats).
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:
To debug and check the standard processing logic you can refer to the BADI FIEB_MAPPING_X and the relevant BAdI implementation with corresponding filter value based on the FF_5 selection.
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 directly in the DMEE tree or in the corresponding BAdI.
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).
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.
In the RFEBKA00 report select the pain.002 format as per the customizing and select Payment Status.
Based on the data in the pain.002 file and based on the customizing a document should be posted and the original payment document canceled.
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.
Okumaya devam et...
Pain.002
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).
Process Flow
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.
Prerequisites
The necessary customizing for this solution is described in the prerequisite notes 1957980 and 2311257.
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.
Note: This prerequisite is covered in the standard SAP delivered formats CGI_XML_CT and CGI_XML_DD (SAP Notes 2253571, 2784858).
If the above prerequisites are fulfilled, the SAP system should have no problem finding the correct document to be reversed.
The program logic consists of two main parts – a BADI and a transformation. These can be customized in the activity Define Mapping Procedure (under Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Electronic Bank Statement > Country/Region-Specific Settings > XML Format and Bank-Specific Formats).
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
To debug and check the standard processing logic you can refer to the BADI FIEB_MAPPING_X and the relevant BAdI implementation with corresponding filter value based on the FF_5 selection.
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:
- DMEE_EXIT_SEPA_21
- DMEE_EXIT_SEPA_31
- DMEE_EXIT_SEPA_41
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 directly in the DMEE tree or in the corresponding BAdI.
Example
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.
Testing
The above can be tested during the payment medium generation (tx FBPM) by placing the breakpoint into the function modules.
First, the secondary RENUM is stored into a global variable g_renum:
Then the payment documents are appended to the global table gt_documents.
Lastly, the table is exported to the RFDT database table.
We can also check the database table RFDT to make sure that the entries were exported.
You will not be able to visually read the data because RFDT is a cluster table. However, what you can do is to test the secondary RENUM in the function module GET_DOCUMENTS. You should be able to get all the payment documents for the given batch.
Test of pain.002 upload
In the RFEBKA00 report select the pain.002 format as per the customizing and select Payment Status.
Based on the data in the pain.002 file and based on the customizing a document should be posted and the original payment document canceled.
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.
Okumaya devam et...