- SAP Managed Tags:
Payment request is a business process when the payee requires a payment from the payer. It may initiate from any business objects such as invoicing, dunning processes and so on. After reading this blog post, you will understand the business flow, data processing, and implementation of payment requests.
The workflow of payment request in Contract Accounting (FI-CA) includes (1) creation of payment request, (2) outbound processing, (3) inbound processing and (4) internal data flow. In the following sections we introduce them in detail separately.
The objects of the payment requests are documents which can be printed and sent to payers for payments. Business objects such as invoices, dunning letters etc. are standard features in the SAP database. Payees can implement the processes by activating events based on different conditions. The standard functionalities and implementation are parallel.
The below flowchart depicts the outbound and inbound processing between the payee and the payment provider.
The outbound processing is a communicative process with a payment provider initiated by a payee. The payee needs to create a request, such as a QR code. There are two options to process documents: (1) batch processing (with traction FPYR) or (2) immediate/individual processing. The payee can choose one processing channel for communicating with payment providers based on their contracts.
You can find the comparison table below between different processing channels. The chosen processing channel also determines the following flows in the inbound process.
After the payee sends requests to the payment provider, the payment provider replies the result of the request. It is the start of inbound processes. There are two probable scenarios during the inbound processing.
The inbound processes include two types of data: return data and payment confirmation. Returned data is a response to the initial payment requests. It may contain:
The payment confirmation contains details of the payment such as payment amounts or end-to-end session ID which is decided by the payment provider. It also generates a payment lot in the form of SAP standard table. The creation of a payment lot means the invoices being cleared.
If you are interested in the case of localization of payment request supported by FI-CA, you can read the blog post about PIX incoming payment in Brazil.
When the payment is confirmed, the data which was stored in the clearing proposal will be copied to the payment lot (ex: number of business partners and so on) The copied data from the clearing proposal together with the payment confirmation from the payment provider compose the payment lot and mark the clearance of invoices.
Except for the standard process of payment requests, payees can cancel existing payment requests. There are two possibilities in this process:
With the condition of an expiration date, the payee doesn’t need to create cancellation additionally. Instead, the payment provider cancels it with the arrival of expiration dates. Payees have set up the payment request with an expiration date and the exact expiration date.
You have completed the following steps before starting the payment requests.
For more detailed information about payment request procedure, please refer to the latest documentation in SAP Help Portal
Is this blog post useful? Do you have any further comments regarding this topic? Please don’t hesitate to share your thoughts in the comment section below.
FI-CA Payment Request
The workflow of payment request in Contract Accounting (FI-CA) includes (1) creation of payment request, (2) outbound processing, (3) inbound processing and (4) internal data flow. In the following sections we introduce them in detail separately.
Creation of payment request
The objects of the payment requests are documents which can be printed and sent to payers for payments. Business objects such as invoices, dunning letters etc. are standard features in the SAP database. Payees can implement the processes by activating events based on different conditions. The standard functionalities and implementation are parallel.
Outbound processing
The below flowchart depicts the outbound and inbound processing between the payee and the payment provider.
The outbound processing is a communicative process with a payment provider initiated by a payee. The payee needs to create a request, such as a QR code. There are two options to process documents: (1) batch processing (with traction FPYR) or (2) immediate/individual processing. The payee can choose one processing channel for communicating with payment providers based on their contracts.
You can find the comparison table below between different processing channels. The chosen processing channel also determines the following flows in the inbound process.
| Processing channels | Usage |
| Synchronous API | Payment Provider’s payment reference data (return parameter of API call) is saved to the payment reference |
| Asynchronous API | Payment Provider is asked to send the payment reference data. Data will come through inbound process (Bank Statement) |
| DME | An outgoing file is created and sent to the Payment Provider. Data will come through inbound process (Bank Statement) |
Inbound processing
After the payee sends requests to the payment provider, the payment provider replies the result of the request. It is the start of inbound processes. There are two probable scenarios during the inbound processing.
- Payee who sent requests through asynchronous API or DME file gets return file through DME file. Meanwhile the bank statement is uploaded and transferred to FI-CA.
- Payee who sent requests through synchronous API gets return parameter as a synchronous call.
The inbound processes include two types of data: return data and payment confirmation. Returned data is a response to the initial payment requests. It may contain:
- Returned status code (ex: registered, canceled, expired, or rejected)
- Returned error codes
- Returned payment reference data (ex: QR Code)
The payment confirmation contains details of the payment such as payment amounts or end-to-end session ID which is decided by the payment provider. It also generates a payment lot in the form of SAP standard table. The creation of a payment lot means the invoices being cleared.
If you are interested in the case of localization of payment request supported by FI-CA, you can read the blog post about PIX incoming payment in Brazil.
Internal data flow
When the payment is confirmed, the data which was stored in the clearing proposal will be copied to the payment lot (ex: number of business partners and so on) The copied data from the clearing proposal together with the payment confirmation from the payment provider compose the payment lot and mark the clearance of invoices.
Invoice cancellation (Transaction FP08)
Except for the standard process of payment requests, payees can cancel existing payment requests. There are two possibilities in this process:
- The existing payment request didn’t enter the communication stage, that is, before the start of outbound processing. In such case, payees can cancel the payment request without involving the payment provider.
- The existing payment request entered the outbound processing and thus involves the payment provider. The process will be the same as the payment request with the reply that the payment request is cancelled.
Payment request with an expiration date (Transaction FPPRQD)
With the condition of an expiration date, the payee doesn’t need to create cancellation additionally. Instead, the payment provider cancels it with the arrival of expiration dates. Payees have set up the payment request with an expiration date and the exact expiration date.
- Setting payment request with date of expiration: transaction SM34 with view cluster VC_TFKPRQ and choose “cancellation by PSP in Categories > Return Status
- Setting the date of expiration FPPRQD
Technical information
Prerequisites
You have completed the following steps before starting the payment requests.
- You have set up the Payment Request Processing in Processing Customizing activity in transaction SM34 with View cluster VC_TFKPRQ
- You have created a payment method in Transaction FQP1 with entering appointed format in the Payment medium format group box. This payment method is used in the payment request run (transaction FPYR).
Customizing
- Post business objects. When you process a business, the system generates a payment reference ID and a payment request. The reference data is then stored in the Payment Request - Reference (DFKKPRQRI) database table, and all the payment request data is stored in the Payment Request (DFKKPRQ) database table.
- Execute a payment run.
- Check and monitor your payment requests using the Payment Reference Monitor report.
- Submit the payment request or requests to your payment provider using the Payment Request Processing (transaction code FPYR) report.
- Your payment provider sends back a return file, including the following data:
- The return status of the request, or
- The returned error code (stored in DFKKPRQ)
- The returned payment reference data (stored in DFKKPRQRID)
- Import the return file into your system with the Bank Statement: Various Formats (SWIFT, MultiCash, BAI...) in transaction FF_5
- If the request is successful, the reference data is imported and stored in the Payment Request - Reference Data (DFKKPRQRID) database table. You can print the invoice with QR code or URL, etc. and submit it to the payer.
For more detailed information about payment request procedure, please refer to the latest documentation in SAP Help Portal
SAP notes
- To learn more about the payment request framework, you may refer to the SAP note 3101304 - Payment Request Framework - Collective SAP Note for Contract Accounting (FI-CA)
- To see the localization case of payment request in Brazil, you can refer to the SAP note 3028556 - Brazil: PIX Payments - Collective Note for Contract Accounting (FI-CA)
Is this blog post useful? Do you have any further comments regarding this topic? Please don’t hesitate to share your thoughts in the comment section below.
8 Comments
