Introduction of FI-CA Payment Request
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.
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.
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.
|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)|
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
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).
- 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
- 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.
Thanks for valuable knowledge sharing blog
Very informative blog
Good article!!!, Thanks.
Is there a SAP delivered Payment lot proposal functionality? I know we have the Broker report proposal function, but could not find Payment lot proposal function. Please advise if anyone aware of Payment lot proposal function.
Never mind, we can use FPAY1B (Payment Specification for Payment Lot) or Payment Advice Note (FPAV) before executing FP05 to post the incoming payments.
You are right that the Payment Specification is one of the Payment Lot clearing proposal options, but it is not the only option. Our developer provided another option in the explanation as below.
Any of the existing options (Selection Categories and their values) will be taken over to the Payment Lot item if they are saved during the Payment Request creation using the input parameter IS_PRQ-T_CL when calling the creation method CL_FKK_PAYREQ=> CREATE_PRQ_CREATION.
Payment Specification (PDKEY) or Payment Form (NRZAS, RFZAS) are the typical options if some particular receivable items should be selected for clearing.
Thank you for the question.
Thank you Cheng-Hua. Appreciate your response.
The only downside of the payment request is that we cannot split the receivables at the document level to apply a partial payment when creating the payment specification request. Do you know the functionality is available within the payment specification to perform a partial pay? Please advise.
Very good blog. One question that I have - would an advance request by an employee say a travel advance request or a salary advance request, qualify under FI-CA payment request? So here the payee is employee and the payer is employer.
FI-CA (Contract Accounting) is a type of invoicing in which receivables and payables expected from or owed to a business partner. The receivables and payables are continually updated in a contract account and periodically transferred to the general ledger in aggregated form.
Back to your question, the payment between employees and employers is not in the scope of FI-CA. The FI-CA payment request is restricted to those who is a business partner with contract accounts, so employee is not the case. Furthermore, the payment provider is a bank, or a third party, instead of the payer.
Thank you for the question.