Friday, 15 April 2016

Automatic Merging of Manual Payments

Payments are sent to BCM as a result of day to day operations in the Treasury module. After running the Manual payment, payments will be further processed in BCM

Manual Payment Transaction Code:

Vendor Manual Payments :FIBLAPOP

Customer Manual Payments :FIBLAROP

G/L Manual Payments : FIBLFFP

Once the manual payments are triggered, the same needs to be merged manually using transaction code FBPM1.

Current State : Currently share services is manually merging the manual Payments using transaction code FBPM1

Requirement: To perform this activity automatically

Solution Implemented : The shared services wanted to automate the process once the manual payments are executed, so in order to facilitate the same we have created a new Transaction code (With the help of ABAP Development team) which upon execution will automatically perform the merging functionality for Manual Payments

New Transaction code

Vendor Manual Payments :ZFIBLAPOP

Customer Manual Payments :ZFIBLAROP

G/L Manual Payments : ZFIBLFFP

Screen shot o Manual Payments for Vendor 




Once the user performs the Manual Payments in order for the system to trigger the automatic merger using transaction code FBPM1 the user needs to click on Back button as shown in the below screen shot



Tuesday, 15 March 2016

Bank Communication Management - Reversing Payment


Overview


The concepts and steps provided in this documentation are intended to give you a basic understanding of the automating the process of reversing the payment document once the file has been rejected by the bank, rather than end user manually reversing the payment document.

The xml file created as part of BCM will be sent to SAP PI via the proxy output. Then SAP PI will convert the output in to ISO pain format and sent the same to relevant bank via swift connectivity.

Once we send the payment file to bank we receive two levels of acknowledgment; the first one is File level (Received by the Bank); and the 2nd level acknowledgement is transactional level (Accepted By Bank / Rejected By Bank).

The current process is for transactional status (2nd Level Ack) wherever we have ('RJCT') rejected status; the shared services team has to manually reversing the payment documents using the standard SAP process (Transaction Code: FBRA).

The requirement is to automate the payment document reversal process.

Current SAP process


The bank may reject the few payment documents within the Batch due various reasons such as,
               1)      Due incorrect account number or
               2)      The bank account may not be correct or
              3)      For any other reason

 Normally when the payment document are rejected by bank , the share services team has to manually check each batch and see which payment documents are reject and the reason behind the  reject.

Once the error is rectified the shared services team have to manually reverse the payment document using transaction code FBRA – Reverse and resetting which will reverse the clearing document and will be available as open item to be processed again for the next payment run.


 Proposed solution


We want to automate this process which will reduce the manual work of reversal of payment document by shared services

A new development program needs to be developed which should automatically reverse the reject document based on the Rejected Status in BCM and a mail should be sent to the distribution list specifying the batch , company code, payment document number, rejection reason which has been Automatically reversed by the system.

Also after the reversal the invoice / credit notes will be re-opened and available for next payment run. The requirement is to update the payment block for these open items; so shared services will review these to correct the error before processing the next payment run for these items.

A job will be run on daily basis which will pick the rejected payment documents. The shared services has to monitor the batch to see the reason why the payment has been rejecting on daily basis. Once the reject reason has been rectified by shared services  the open item can again be picked for the next  payment run

Analysis:

Based on the rejected status the system should pick the Run date and the Identification from the batch. Based on this details the system should collect the clearing document number, company code, fiscal year details from REGUH Table and use the transaction code FBRA to automatically reverse the document. A mail should be automatically sent to the selected user list specifying the payment document has been reversed specifying the document has been reversed with xxxx Document Number.

Currently the process is being Manually Handled in shared services
Screen shot of FBRA transaction code





Example
Batch 2502 has Rejected Status
   The Batch has Run Date: 17.02.2013
   Id: @ NL



  
Now go to Table REGUH and enter the Run date and Id as shown in the below Screen shot to get the details of Company Code, Clearing document Number and Fiscal Year.


 

 


The system based on this details should go to Transaction code FBRA and reverse the payment document  and a mail should be sent ot selected user that the payment document has been reversed




Logic to be Implemented
New Program to be developed
We need to build a new bespoke program which should extract all the rejected payments and reverse them automatically; also at the same time update the payment block in the re-opened items.

Selection Screen:

1) Creation Date  (From :             To:              )  --> Mandatory
2) Batch Number
3) Company Code
4) Payment Document Number
5) Fiscal Year

Logic:

Based on the Creation Date we need to extract the batch numbers from table BNK_BATCH_HEADER
For these batches we need to extract the item number, Company Code, Fiscal Year and payment document from BNK_BATCH_ITEM
Then we need to check the status for these items in BNK_XSTAT_TX; wherever we have 'RJCT' status; we need to call FBRA function module and pass the relevant info.
Before reversing Check in Table BKPF to see if the document has been already reversed
Logic is Reversal Indicator BKPF-XREVERSAL should be EMPTY.
Also before reversing we need to find the linked invoices / credit notes:
BSAK (vendor) and BSAD (Customer) tables to derived the linked open items for the relevant payment document. (Payment Document = Clearing Document & pick only invoice and credit notes).
After the reversal we need to update the payment block.
Rejection reason extract from BNK_XSTAT_RSN
Once the payment documents reversed; we need update the payment block in the open items.

Output Log:

Batch Number, Item Number, Rejection Reason, Company Code, Payment Document number, Fiscal Year; also include the open items which were re-opened after the reversal.

Table from where data can be extracted
Reason for rejection - BNK_XSTAT_RSN
Table to see Accepted/rejected status -  BNK_XSTAT_TX
BNK_BATCH_ITEM

Logic to be implemented

Extraction of Rejected document from Table BNK_XSTAT_TX
In the table if the Status Info is RJCT select Document number and Item number and Batch number from this table


Now based on the batch number 2326 and Item number extract the company code Fiscal year and document number from table.


Check in Table BKPF to see if the document has been already reversed.
Logic is Reversal Indicator BKPF-XREVERSAL should be EMPTY.
Now based on the above information create a functional module to reverse the document and a log needs to be generated to send the details of the

Payment Document number
Company code
Fiscal year
Reversed Document
Reason for Rejection

A CMT job will be run on daily basis to reverse the documents.