In this blog, I am going to cover the procedure to process incoming messages (PAIN.002) using Multi-Bank Connectivity as part of advanced payment management functionality.
The below architecture explains the standard procedure to connect the SAP ERP or SAP S/4HANA systems to Financial institutions.
Source sap
Process Overview:
- To process the inbound messages(PAIN.002), as a pre-requisite, it is a must to set up SAP Multi-Bank Connectivity Connector (available from SAP S/4HANA 1909 or Higher ) as described in Connector for SAP Multi-Bank Connectivity to import payment messages coming via SAP Multi-Bank Connectivity.
- In this blog, we are focusing on the Payment Acknowledgments, i.e. when the payment got accepted or rejected, addressing the system behaviour as part of Status management.
- We should define the Inbound processing Steps & PAIN2 Inbound Converter ID to hand over the messages to advanced payment management for processing. The definition of Converter ID can be maintained in a combination of Message Type, Sender ID, Receiver ID and Origin.
- SAP standard-delivered converters use the XML converter, which means, they are converted internally into an XML representation. Therefore, certain XML schema definitions are provided based on XSD Schema.
- Forwarding Status: Forwarding Status is the response to Acknowledgements sent by the bank
- In Standard SAP advanced payment management, the System processes PAIN.002 messages using “OrgnlMsgId” & “OrgnlInstrId” and doesn’t consider “OrgnlEndToEndId”. In case “OrgnlInstrId” is not available, only such situations system will give priority to the “OrgnlEndToEndId” with the combination of “OrgnlMsgId”.
- Batch Number: If we process the PAIN.002 in advanced payment management & Bank Communication Management the batch number will get updated on Both the incoming and outgoing side, with the help of the Batch number we can track the messages by Batch.
I like to cover relevant important configurations in Advanced Payment Management for processing PAIN.002 Messages.
Define Inbound Converter
SPRO-->Financial Supply Chain Management-->Advanced Payment Management -->External Interfaces--> File Handler--> Basic Configuration--> Define Converter(new)
Create a New Converter ID under a combination of Format, Medium and Channel that differentiate the payment format. Origin “External” is required as the message file comes from the Bank.
Next, ensure the conversion program that converter ID SAP will derive the relevant class automatically.
As we are using Multi-Bank Connectivity in this scenario, it will import directly. Else, it is a must to define the Directory Logical File Name and Logical File.
Define XML Settings for Format Converter
SPRO-->Financial Supply Chain Management-->Advanced Payment Management--> Payment Processing--> External Interfaces--> File Handler--> XML Framework--> Define XML Settings for Format Converter
XML converter attributes are requires to have automatic converter derivation by using BAdI’s. I have listed relevant BAdIs at the end of this section.
Maintain Processing Steps for Inbound Messages
SIMG--> Multi-Bank Connectivity Connector--> Inbound Processing--> Maintain Processing Steps for Inbound Messages
In this step, we maintain application-specific inbound processing steps. A processing step is defined as an assignment of an application that should be triggered for processing of the payload received by SAP Multi-Bank Connectivity message (MULTI-BANK CONNECTIVITY message). The assignment is made for message types that are received in the header information of a Multi-Bank Connectivity message. we can define several steps for each application and must define different step numbers when assigning several applications to one Message Type. Activation/deactivation of the application process is a must to trigger the processing step.
Now I have created a message type for PAIN.002 that updates advanced payment management & Bank Communication Management
Define Forwarding Status
SIMG--> Financial Supply Chain Management--> Advanced Payment Management--> External Interfaces--> File Handler--> External Status--> Forwarding Status--> Define Forwarding Status
Forwarding status is required to map the external status received from the Bank when processing payment orders and get updated in the SAP system. It manages the message status and also exception handling.
Assign External Status Categories for Bank Messages
SIMG--> Financial Supply Chain Management--> Advanced Payment Management--> External Interfaces--> File Handler--> External Status--> Assign External Status Categories for Bank Messages
It also requires to creation of external status categories for messages received from banks to set the classification of messages which will be used for data reconciliations.
we can classify each entry into one of the following categories:
Completed:
This will finalize pending files, orders, and transactions and then trigger subsequent actions. This can include the further processing of pending clearing items (CLR) to be posted to the G/L (if we activate bank confirmations).
Rejected:
This will trigger the exception-handling framework to deal with the error scenario. You can either specify the exception handling reaction based on the provided error reason code (see also the activity Assign Exception Handling Reactions to Bank Rejects), use an error code based on the configuration in the activity Define Default Reaction Types, or the master data setup via the transaction /PF1/EH (Manage Exception Handling Rules).
If bank-specific values are not configured, the system will use those entries without the specified bank. If no configuration is provided for the status code, default settings will be applied as follows:
ACSC and ACSP status codes were simply completed.
RJCT and CANC status codes are handled as rejected.
All other codes will be handled as intermediary information, which will be followed by a status of either category Completed or Rejected.
Assign Exception-handling Reactions to Bank Rejects
SIMG--> Financial Supply Chain Management--> Advanced Payment Management--> External Interfaces--> File Handler--> External Status--> Assign Exception Handling Reactions to Bank Rejects
To handle the bank rejections, it is possible to assign exception-handling reactions to the relevant bank reject messages. Reason code can be used to identify the proper handling of the rejected file, order or transaction.
If no specific reaction type is defined, the activity Define Default Reaction Types or the master data configuration (transaction /PF1/EH: Manage Exception Handling Rules) will be used for the standard error code Bank Reject (002010).
Define Response Types for Rejection
SIMG--> Financial Supply Chain Management--> Advanced Payment Management--> Exception Handling--> Define Response Types--> General Response Types--> Rejection-->Define Response Types for Rejection
We can create response types for the rejection of payment orders and/or payment items and a final response type for the new response types. assign an existing return reason.
Maintain Alternative Transaction Types for Rejected Items
SIMG--> Financial Supply Chain Management--> Advanced Payment Management--> Exception Handling--> Define Response Types--> General Response Types--> Rejection--> Maintain Alternative Transaction Types for Rejected Items
We define the transaction type that is used to post a transaction into its respective rejection/return category. we can distinguish transaction types by their applied return reason code. A transaction type and what it returns is dependent on the defined revision reason (return/reject reason).
Usually, reject transaction types are assigned to a different enrichment and validation group. They do not have to fulfil standard business checks. Additionally, a dedicated transaction type provides an easy way to distinguish returns/rejects from regular transactions in advanced payment management and in attached accounting systems. We have defined regular transaction types and reject transaction types with an identical indicator for debit/credit.
Define Default Reaction Types
SIMG--> Financial Supply Chain Management--> Advanced Payment Management--> Exception Handling-->Define Default Reaction Types
We can assign reactions for different errors occurring in the system. This information will assist in exception handling master data configuration. Master data configuration will be filled dynamically with the configured information.
we need to define the reaction types required for your system based on business requirements.
advanced payment management standard provides two options for Exception handling i.e. at configuration or Master data (/PF1/EH). In this blog, I considered the Configuration level exception handling.
Maintain Multi-Bank Connectivity Connector Inbound Settings
SIMG-->Financial Supply Chain Management-->Advanced Payment Management-->External Interfaces--> File Handler--> Multi-Bank Connectivity Connector Integration--> Maintain Multi-Bank Connectivity Connector Inbound Settings
It is a must to assign the message type with a converter ID that processes the inbound messages received via a Multi-Bank Connectivity connector with a combination of sender and receiver. Using Multi-Bank Connectivity RFC-based API, the XML will be routed and handed over to advanced payment management.
SIMG-->Multi-Bank Connectivity Connector-->Routing and Connectivity-->Maintain RFC API Settings
With the help of the Multi-Bank Connectivity, we can define the settings relevant to the RFC-based API (SM59) of the connector for SAP Multi-Bank Connectivity. we maintain the entries, we can leave the fields Receiver ID and Origin blank. In such cases, when the system reads the configuration table, it treats the blank fields as * wildcards. When reading the table, the system always checks for the most specific entries and only reads wildcard entries as a fallback when no fully qualified entries can be found.
End-user Manual
Let us go through the PAIN.002 process how it updates the advanced payment management through Multi-Bank Connectivity. As a pre-requisite, We are using the RFC-based API PAIN.001.001.03 directly imported from the different external systems in Multi-Bank Connectivity Inbound which is imported to advanced payment management.
Go to the Fiori App “Manage bank Messages” to handle bank messages. Here we can see if the file was processed from an external system to advanced payment management.
Click on Drill down which appears on the below screen
Click on the “Display Processing steps” to view the step wise processing status
View the log to view the detailed steps of the process and validate for errors
Now go to the Fiori App “Manage Payments” to view the payment details processed to advanced payment management through Multi-Bank Connectivity. Based on the Selection criteria, it displays one order which represents the incoming order.
In order to process outgoing payments, Payment Batches will be managed through the Fiori App “Manage Payment Batches” where the system will Collect multiple incoming orders and process them as a single outgoing order based on predefined conditions under the clearing agreement.
Now Select the item and click on Process (or We can use the /PF1/POLLER - Payment Batch Processing) that schedules the job in the background.
The system will process relevant batch and status change from Open to Completed.
If we see the order details in the “Manage Payments” Fiori app, it does generate two orders i.e. Incoming and Outgoing orders processed.
For Each Incoming order it does display three Segments Originator, Recipient & General Order Data for payment on behalf, In Name of Routing & In Name of Forwarding. Let us see the detailed information below on each segment.
Originator:- Sending (Subsidiary) Company code information, Send bank Account Information (Subsidiary bank Account), Service Level Agreements, Internal route, Clearing Agreements & Process flows
Recipient:- Beneficiary Bank Account details, EndtoEndID, Service Level Agreements, route, External Clearing Agreements & Process flows and it will identify the head office bank account which external paying bank account
Even outgoing payment order also has three Segments i.e. Clearing, Recipient & General Order Data for payment on behalf and In Name of Routing (In Name of Forwarding it has three segments Originator, Recipient & General Order Data)
Clearing:- Head office Company code information, External bank Account Information, Service level Agreements, Internal (GL) route, Clearing Agreements & General ledger accounting Documents.
By Clicking on the hyperlink of the GL Document in the above screen, it does display the relevant accounting document posted at the recipient level.
Recipient:- Beneficiary Bank Account details, EndtoEndID, Service Level Agreements, route, Clearing Agreements & Process flows
Once the PAIN.001 has been processed (Sent) to the Bank, now we will see the incoming messages. (PAIN.002) received from the Bank and get updated on advanced payment management and Bank Communication Management. In this process, we will see Four levels of different statuses like how the acknowledgement will get updated in advanced payment management and Bank Communication Management with Acknowledgement levels i.e. ACTC, PEND, ACSP, RJCT.
- ACTC--> which will be file-level acknowledgement.
All the messages received from the Bank will be displayed in the “Manage Bank Messages” Fiori app. The below Screen Represents that when the PAIN.002 is received from the Multi-Bank Connectivity tenant to Multi-Bank Connectivity Connector the Process Automatically and the Status will get updated in the Manage payments Fiori App & Monitor Payments Fiori App.
Click on the right arrow (>) which displays detailed message information such as Bank Communication Management Batch number, Sender ID, Receiver ID, message ID, Message type, File name and extended header details.
Click on the Display processing steps, it will show the processing details.
In the below screen shot you can observe that payment status is getting update in both advanced payment management & Bank Communication Management.
Click on the Log to display the detailed log information. We can see the detailed information for the status acknowledgement log below.
Click on
Now check the Fiori App “Manage Payments” which displays two orders which represents incoming payment order and outgoing payment order.
External Status will get updated.
Click on the Object List that shows external status details. One Object list is responsible for all the external status updation for the ext
In advanced payment management based on the PAIN.002 tag, the “OrgnlMsgId” system will identify the Object list and update the status in the Recipient party Item and general order data
Click on the Recipient Party Item
Click on General Order Data.
- PEND--> This will be sent from the bank side if it is due date or value date if future dated which will be Transaction level status acknowledgement.
All the messages received from the Bank will be displayed in the “Manage Bank Messages” Fiori app. The below Screen Represents that when the PAIN.002 is received from the Multi-Bank Connectivity tenant to Multi-Bank Connectivity Connector it is Process Automatically and the Status will get updated in the Manage payments Fiori App & Monitor Payments Fiori App.
When we click on the processing steps it will display processing details.
In the below screenshot, you can observe that payment status is getting updated in both advanced payment management & Bank Communication Management
Got the Fiori App Monitor Payment Based on selection data will be displayed, In the below Screen the status will get updated in the header level
Based on the drill down right arrow (>) which displays detailed message information such Bank Communication Management Batch item will be displayed
Now check the Fiori App “Manage Payments” which displays one orders which represents an outgoing payment order. Based on the Selection it is displaying one orders which represents outgoing payment order based on selection. In advanced payment management based on the PAIN.002 tag “OrgnlMsgId” and “OrgnlInstrId” or “OrgnlEndToEndId” system will identify the Object list and update the status in Recipient party Item and general order data
Check on Drilldown
Based on object list Selection
Click on the Recipient Party Item
Click on General Order Data
- ASCP--> Transaction level status acknowledgement.
All the messages received from the Bank will be displayed in the “Manage Bank Messages” Fiori app. The below Screen Represents that when the PAIN.002 is received from the Multi-Bank Connectivity tenant to Multi-Bank Connectivity Connector it is Process Automatically and the Status will get updated in the Manage Payments Fiori App & Monitor Payments Fiori App.
Based on the selection it will be displayed
Got the Fiori App Monitor Payment Based on selection data will be displayed, In the below Screen the status will get updated in the header level
Based on the drill down right arrow (>) which displays detailed message information such Bank Communication Management Batch item will be displayed
Based on the selection data will be displayed
Got the advanced payment management (Advanced Payment Management APP and select the Manage Payment)
Now check the Fiori App “Manage Payments” which displays one orders which represents an outgoing payment order.
Based on the Selection it displays one order which represents an outgoing payment order based on selection
ACSP is the final payment status confirmation in the Processing status is converted from 230 to 240 which means “payment medium created” to “Outbound Processing Completed”
This is happening due to the configuration Define Forwarding Status where we are selecting status has final
- RJCT--> If the bank rejected the file Transaction level status acknowledgement.
Got the Fiori App Monitor Payment Based on selection data will be displayed, In the below Screen the status will get updated in the header level
Based on the drill down right arrow (>) which displays detailed message information such Bank Communication Management Batch item will be displayed
Got the (Advanced Payment Management APP’s and select the Manage Payment)
Now check the Fiori App “Manage Payments” which displays one orders which represents an outgoing payment order.
Based on the Selection it displays one order which represents an outgoing payment order based on selection
RJCT is the Rejection payment status updated then the system pressing status is converted from 240 to 273 which means “Outbound Processing Completed” to “Rejected”.
Click on Drilldown
Click on clearing Item.
In the initial outgoing payment order, we have only a Credit clearing item with Value, based on rejection from the bank debit clearing item was generated and a subsequent accounting document was also generated.
In the below Screenshot in accounting document, an offset adjustment was posted
Click on the Recipient party item
Based on the rejection you can observe Recipient party item has been detached from the outgoing payment order based on bank rejection, this reaction happened because of the exception handing the RCP Item will be returned to the Incoming payment order.
Conclusion: - Below are takeaway points to be considered for this SAP S/4HANA Advanced Payment Management for payment Acknowledgment status
- For scenario:- “In Name of routing” / “Payment on behalf scenario” for payment Acknowledgments status there will be an accounting impact based on exception handling.
- If the Customer is not using Multi-Bank Connectivity then please use the transaction /PF1/FH_IPM_EXPERT or /PF1/FH_IMPORT_DIR
- In your bank statement you are receiving the rejected items, please set RJCT status as forwarding status without exceptions and set it to final.
Special Thanks for all the input guidance and motivation to: Andrea Richter , Jens Kuehnle & Prakash Javvadi
- SAP Managed Tags:
1 Comment
