Challenges of double Payments in SAP

[former_member230276]

WHITE PAPER

Abstract
SAP Bank Communication Management typically provides usage of payment media generated with the help of a payment program (F110 or F111). The file will be downloaded to a file server, then the file is uploaded to a 3rd party system, which takes over the arrangement of the transmission of files to and from the bank. There are possibilities for some slippages in payment process. Payment files can be sent to the bank twice. There is a risk of double payments to vendors/customers. This white paper explains how technology can be best utilized with additional development of SAP in order to meet the business requirements.

Background
Scenario

SAP Payments

In SAP, payments can be classified into Wire payments using BCM or non BCM. For a bank, which is connected to SWIFT network, BCM is the best practice for payments in SAP. Depending on the payment medium attached to the payment method, the system determines which payment medium has to be used. Following are the payment mediums discussed in this white paper.

 Payment Run (without Bank Communication Management)
 Payment Run (with Bank Communication Management)

System Limitation in Payment process

Payment Run (without Bank Communication Management)
When a payment is processed in SAP for non BCM payment scenario, payment files are created based on the DMEE tree attached to the payment method. During payment proposal in F110/F111 the system gives an option to create a payment medium file.

If the create payment medium is checked during the payment proposal and payment run, the system creates two payment files; one for payment proposal and other payment run.
There is a risk of double payment files sent to bank against same vendor invoice.
Payment Run (with Bank Communication Management)
When a company code is maintained in OBPM4, payments are routed through the Bank Communication Management. The system basically checks the payment identification maintained in OBPM5 and determines the payment (BCM or non-BCM payment).

SAP does not restrict the user to execute a payment run for Company code, which is maintained in OBPM4 outside the Bank Communication Management. A user can process a payment (BCM related company code) without BCM identification (OBPM5), create a payment file based on the DMEE tree and send a file to Bank. Later, after analysis, the payment document can be reversed in Finance and re-process a payment run with BCM identification and process (sending a file as a batch) payment file to bank.

There is a risk of double payment files sent to the bank against same vendor invoice.

Business Requirement
The payment processed through SAP payment program (F110 or F111) and payment file (ISO 20022 XML) to be checked (for double payments) in SAP and encrypted before sending it to service provider.

SAP Solutions

Non BCM payments
Please refer SAP note 1566148, forbid file creation for non-BCM payment runs from proposal, we can do this via authorization (Authority – Check object “F_REGU_BUK”, ID FBTCH field “15”, create file from proposal. This authorization is checked from transaction F110 and from SAPFPAYM.

BCM Payments
Refer SAP note 2192212, the module FIBL_PAYMENT_RUN_MERGER_DELETE is enhanced with the optional IMPORTING parameter I_XVORL type XVORL. After implementing these changes, an entry is made in the table REGUVM for the F110/F111 proposal run if BCM is active.
We can address double payment file creation in BCM with following variant setup. In OBPM4 (payment medium variant selection) for a Company Code  Select the variantclick edit variant. Select check box in output control (payment document validation).

When we select the payment document validation, system basically checks if payment document is reversed in Finance (FBRA) before creating payment batch (FBPM1). If the payment document is reversed in FI before creating payment batch, FBPM1 will not pick-up the payment document in the batch.

Alternative Workaround Solution

Logic of FBRA exit to check payment in a BCM active batch

1. Pick up document number along with Company code


2. Go to table BNK_BATCH_ITEM with following parameters
   
   
   
   1. Paying company code – ZBUKR
   
   
   2. Payment document number – VBLNR
   
   
   
   


3. Pick up the batch numbers filed “BATCH_NO”


4. Go to table BNK_BATCH_HEADER with following parameters
   
   
   
   1. Batch Number - BATCH_NO
   
   
   2. Blank in field checkbox – “XRESET”
   
   
   
   


5. Pick the batch number where field “XRESET”, value is blank


6. Update an internal table “Reversal_Batch” check with following
   
   
   
   1. Paying company code – ZBUKR
   
   
   2. Payment document number – VBLNR
   
   
   3. Batch Number - BATCH_NO
   
   
   
   


7. If a batch is updated in Z table “Reversal_Batch” against the payment document VBLNR and company code – ZBUKR,
   
   
   
   1. Trigger a message, document “XXXXXX” (entered) is included in a BCM batch (XXXX from internal table Batch Number - BATCH_NO). Payment can’t be reversed.
   
   
   
   

With the above configuration, we can control duplicate payments from Bank Communication Management.

Blocking BCM related payment files not generated outside Bank Monitor
SAP does not block to process a payment run for a Company Code with BCM setup. There is a risk to process a payment run and send a payment file to the bank with batching of the payment into a payment batches. This can exclude the approval process of BCM.

To avoid such risk, we can have a user exit in place to check the BCM related payments and restrict the payment proposal created with BCM identification. We need to use the below mentioned logic to create a user exit

Payment date and payment run identification are the very first steps under parameters. The payment run ID is caught in BCM by a simple starting-letter of the payment run ID, letter ‘B’. E.g. if the payment run ID is ‘B100’, it will be included in BCM while ‘1000’ will not be included. The BCM validation solution must make sure that BCM relevant payments are recognized by the system as BCM payments, and prevent that non-BCM payments get executed as BCM payments. To support the future automation of proposals - and payment runs, BCM validation will happen during step 2, the scheduling run. Depending on the entered payment method and the corresponding payment format, either the run is executed or an error message is displayed (error message to support both dialog - and batch job mode).

During scheduling of F110 system checks the payment methods which are related for BCM. These payment methods are identified using payment medium workbench (DMEE). If the payment method is not part of the DMEE, e.g. Check payments or Manual payments, payment does not qualify for BCM irrespectively of the payment run ID starting with B. SAP only supports BCM payments generated through DMEE, which is why this parameter can be used for technical qualifier.

At the time of F110/ F111 execution we are going to check these payment method parameters. If the parameters are met as per BCM qualifier tables of transaction code OBPM5 (table “TFIBLMPAYBLOCK”), system will allow to save the parameter so that it can proceed further, else an error is thrown.

An error will happen, if payment run ID doesn’t hold BCM qualifying details, e.g. ‘1000’, but payment method is ‘A-Standard Payment’. We have Payment Medium Workbench assigned with payment method ‘A’.

The following error will appear
“Please check payment identification is not matching as per BCM”. Error can be defined as per business requirement.

Payment medium workbench can however, not be a stand-alone requirement for BCM qualifying. It is therefore a combination of OBPM5, payment medium format type (‘XX - File’ vs ‘YY - XI-Proxy’) and payment method details that will be used for this BCM validation solution. Please check the payment formats types.

Logic: -
A. For restricting F110 from creating Payment with wrong format of Run ID, a BADI (FI_F110_SCHEDULE_JOB  method CHECK_PARAMETER) need to be implemented.
B. The Run-ID from F110 should be in pattern (TFIBLMPAYBLOCK- LAUFI) where TFIBLMPAYBLOCK-LAUFK = ‘blank’ (means F110) and TFIBLMPAYBLOCK -XBATCH = ‘X’ (BCM active).
C. For each Comp. code and for each payment method, check in T042Z-LAND1 = ‘Country of Comp. code’ & T042Z-ZLSCH = ‘Payment method(s)’ from F110 and fetch T042Z-FORMI (DMEE Tree)
D. Check in table TFPM042F- DTTYP = ‘YY’ for the DMEE found in step ‘C’ else Non-BCM.
E. The 3 conditions (B, C, D) need to be checked at once and if met then identify this as a BCM payment and stop user from executing with a wrong payment run ID else allow as usual.
F. If Run-ID not as per the format for an identified BCM payment run, trigger an error message “Please check payment identification is not matching as per BCM”.

Conclusion
SAP system is intelligently built and best utilized so that the double payment risk can fully be avoided with the SAP standard process like BCM. SAP payment medium (ISO 20022 XML) through batch approvals, encrypts the data and sends it to the service provider (SWIFT).

About Author
Colin Thomas
Colin Thomas has 10 years of domain experience in Financial Accounting and 11 years of SAP experience. His experience in SAP includes business process re-engineering and SAP implementation in Finance and Manufacturing processes. He holds a Master’s degree in Commerce and he is certified by the IFRS and ITIL.