However this document does not deal with Swift Integration, as the payment mechanism varies from
business to business.
Author: Srinivasan Ravichandran
Company: Infosys Technologies Limited
Created on: 19 June, 2011
Author Bio
Srinivasan is a Chartered Accountant and working as a SAP FICO Functional Consultant in Infosys
Technologies Limited, with domain experience of over 4 years.
The following are the benefits derived from implementing BCM process:
Reduction of manual efforts; ensures the payment process is automated
Reduce cycle time of payment processing
Common interface of payment processing, when there are dealing with multiple banks.
Payment runs are batched based on various criteria predefined in the system configuration.
Workflow based approval system ensures that payments are routed through a proper channel with
minimum of manual efforts.
Payment file is generated upon the final authorization and can be sent to bank directly using BCM.
Single point of reporting tool for the status of payments, showing clear visibility to the stake-holders.
The scope of implementation of BCM covers
Implementing Payment Medium Workbench (PMW). PMW is a tool to configure and created payment
media sent by organizations to house banks. The tool replaces the classic payment media programs
(RFFO*).
Implementing Payment Medium Workbench (PMW)
As discussed earlier, implementing PMW is one of the prerequisites for BCM functionality. The basic
concepts of PMW that are relevant for BCM alone are covered in this BoK.
PMW is a tool used to create payment file formats for transferring to banks. The payment medium formats
can be either a classic payment medium program or through the PMW.
There are few SAP standard PMW file formats for various countries. A new format can also be created if
there is a need for custom file format or if there are no other formats available for that bank/ country. This
customization can be either done through modifying the standard function modules of an existing PMW
format or through developing via Data Medium Exchange Engine (DMEE). (However this document does not
deal with customizing through DMEE).
Path: SPRO IMG Financial Accounting (New) Accounts Receivable and Accounts Payable
Business Transactions Outgoing Payments Automatic Outgoing Payments Payment Media Make
Settings for Payment Medium Formats from Payment Medium Workbench
The above path can also be accessed through the T. Codes OBPM1 / OBPM2 / OBPM3 / OBPM4.
Let us briefly go through the steps in implementing PMW:
Create/ change payment medium formats
Assign variant to the format
In our illustration, the standard SAP format ACH has been used.
The formats have been defined using function modules in the form of events.
SAP has predefined the following events and any customizations to the codes have to be routed through the
Sample Function Modules 01, 06, 11, 21 etc. For instance, if there are some changes in Event 20, the same
has to be incorporated in Sample Function module in Event 21. Once event 20 is reached, event 21 will also
be triggered.
Maintain Variants for payment medium formats:
The variant for the payment medium format have to be maintained for the combination of Company Code &
House Bank. This has to be done in the TA OBPM4.
Assign payment medium format to payment method:
In the T Code OBVCU, select the payment method for the country & assign the payment medium format as
per PMW:
This setting is a pre-requisite for BCM functionality.
Rule Currency: For batching rules consisting of various currencies, the currency specified here is considered
as the default currency. In our illustration, it is INR.
Exchange Rate Type: This is used to define different exchange rates. You can use the average rate for
foreign currency translation, and the buying and selling rates for the valuation of foreign currency amounts.
Days resubmission: For resubmission of payments, the date of resubmission from the current date can be
1 day.
Signature required: If you tick this check-box, then the batch approval system follows a digital signature
process. Every time before a batch is approved; a pop-up for the user signature appears.
Payment grouping
Path: SPRO BCM Payment Grouping
This is the activity where we maintain the rules for batching the payments. We need to create rules by
defining a unique Rule ID, giving a description to it and marking a priority. Once the rules are prioritized, the
batching happens according to the priority set in the rules.
After creating and saving the rule, the same has to be maintained using the box.
Then we need to maintain the Attributes to define rules for batches. The attributes can be selected from any
of the given fields like, Amount, vendor, business area etc, depending upon the requirements of the user.
In our illustration, Amount in Local currency has been used. This means that any payment run amount falling
within the given rang will form part of a single batch.
The same way, any number of rules can be framed to fit the user requirements.
We can also set additional criteria apart from the attributes mentioned above. Two grouping fields can be
added which will ensure further batching.
s are first batched on the basis of
Payment status management
Path: SPRO BCM Payment Status Management
Map external status to internal status: In this activity, we can interpret the status codes from the external
world. Any incoming status message has a code which can be mapped to an internal status based on a
company code and house bank. If an alert needs to be triggered for an external status code, we must define
the alert.
Timeout for Batch Status update: In this activity we can specify a maximum allowed time interval between
two status updates. An alert will be triggered after the allowed time elapses.
Bank statement monitor
Path: SPRO BCM Bank Statement Monitor Settings for Bank Statement Monitor
In this activity, we define the settings for bank statement monitor, particular to various house banks.
The above fields are discussed below:
Company code, House Bank, Account ID for which the bank monitor settings are required are to be entered.
Process Status: The processing status indicates whether the bank statement has been processed correctly.
It may be Red, Green or Yellow depending upon the status. To set this status, tick the check box.
Factory Calendar ID: It is used to distinguish between working days and non-working days. In the above
ings relevant for India will
be considered.
Item: -
CITIC-
statement monitor.
Release strategy
Path: SPRO BCM Release Strategy
This is where the crux of BCM lies, because release strategy is the point at which the approval workflow
comes into place.
Automatic payments:
Path: SPRO BCM Release Strategy Mark rules for Automatic Payments
We also have the option to mark any or all of the rules for automatic payment (without using the approval
workflow). This is done in this step:
-box is ticked, then the batches which fall under the specified
rule would not flow through the approval system.
Rs.100000 will be marked for automatic payment.
payment.
In the change and release option, first we assign role to the release steps:
Any user is treated as a role and workflow is assigned for the particular role. The objects pick up the role
from the rule ID specified in this step.
The fields are explained as below:
Release Object: Since the change and release function uses the BNK_INI object, assign the same in this
field.
Release step: This means the Release procedure, i.e., how many processing steps are carried out. It can be
either, dual (01), treble (02) or quadruple (03) controls. This is to be given based on the user requirements.
WF Release Step: For change and release, assign the same as 1
st
Release Step.
Rule: Identifies a rule for user determination in the Framework for the Principle of Dual Control. In this field
you store the eight-digit numeric ID of a rule for user determination.
Next step is to assign user to the new responsibility.
Select the responsibility, Right-click on, and mention the User ID to map the users to
the responsibility.
The following additional points are to be noted in creating responsibilities:
Many users can be assigned to one responsibility
take any effect.
Priority can be assigned to similar objects
Users/ responsibilities can be deleted after creation
Apart from users, the object can also be assigned to Work center, job, position, etc.
for all release objects.
ase objects according to release
procedures and release reasons.
Once the settings are saved, in the main screen of Assign release procedure, choose option to
view all the conditions specified.
The above illustration means that the Principle of Dual control is adopted.
And if the batch value falls between Rs.1 lakh and Rs.10 Lakhs, then its flown to Release reason 1. If the
value is between Rs.10 Lakhs and Rs. 50 Lakhs, batch flows to Release reason 2.
Assign Role to release steps in the additional release steps function is the same as explained in Change and
release function.
Assign workflow to release procedure: In this activity, you can assign a release workflow and a release
procedure workflow to every release procedure of a release object. The release workflow realizes the
technical processing of the release in the system. The release procedure workflows realize the technical
processing of the various release procedures (such as the principle of treble control) in the system.
With this, we come to the end of all necessary configurations for BCM.
Digital signatures:
In case there is a need for digital signatures, then customize these relevant settings.
Path: SPRO BCM Basic settings Basic settings for approval
Under Basic settings, tick the check box
Then, make necessary settings as below:
Under Basis settings, give necessary authorization to the users who will form part of the BCM approval
process.
Then, the next step is to specify signature method:
SAP offers 2 signature methods:
System Signature: After the user has authenticated himself or herself with logon data, the system uses a
digital signature.
User Signature: The user writes the digital signature with his or her own personal key. An external security
product must be installed that implements the SAP SSF interface.
For our illustration purposes, system signature with authorization by SAP user ID/ password is considered.
This means that the same SAP user ID password which is considered at the time of login by the user is used
as transaction ID/ password at the time of approving batches.
Once the user approves & presses the save icon, the digital signature is prompted:
b. Create Batches
Batches will be created based on the logical grouping maintained in the configuration.
Batch to be created using this Path: Path: Environment Payment Medium Cross-Payment-Run-
Payment Medium Create Payment Medium
You can filter for various conditions by using the FURTHER SELECTIONS option in the batch
creation screen.
You can maintain variant for regular processes.
Mention the Run Date and Run ID of the F110 and execute (Press F8) the above screen.
The following dialog box pops up, intimating that the batch has been created using the above 3 payments:
c. Reset Batches
Batch can be reset in case you find some error.
This will remove the merge and bring it back to F110 stage. Payment document will not be reversed.
Use only MERGE DATE AND MERGE ID in the fields.
This is most preferably to be used by System administrator.
To Reset a batch already created, SAP advises to use this program: RBNK_MERGE_RESET.
Call this program from back-end SE38 RBNK_MERGE_RESET.
Fields are explained below:
Run Date: Enter the MERGE RUN DATE (date on which batch was created). DO NOT ENTER THE F110
RUN DATE. To find the Merge Date of a F110 run, please check in T Code BNK_MONIP.
Identification: Enter the MERGE ID (For every batch creation, SAP generates unique merge ID). DO NOT
ENTER THE F110 RUN ID. To find the Merge ID of a F110 run, please check in T Code BNK_MONIP.
Test Run Indicator: It is always better to do a test run before doing a live run.
Strict Check Indicator: If this indicator is TICKED, then batch which is IN APPROVAL CANNOT BE
RESET. Only a NEW BATCH can be reset. If this indicator is NOT TICKED, any batch can be reset.
Once it is executed with relevant inputs, the following screen is generated:
When live run is done, then it says Payment Medium is reset.
d. Process Batches
The following are the batch processing modes available under BCM:
- Approve & proceed with payment: Done by all the levels of users.
- Reject & reverse the entry: Can be done only by verifier.
- Resubmit to a later date: Can be done only by verifier.
- Return the batch to verifier for further action (any of the above 3). Can be done only by approvers.
We will see in detail about each of the procedures below (Illustration list attached for easy reference)
Illustration Batch Reference Remarks
Approve 873 Whole batch approved.
Reject 926 Part of the batch being rejected.
Resubmit 926 Part of the batch being resubmitted.
Return 927 Returned by 1
st
Approver
Called as verification step since this is the only step where you can edit the batches at line item level.
Can do Rejection/ Approve/ Resubmit for part of a batch. For instance, if there are 10 payments in a
batch, you can approve 5, reject 3 and resubmit 2 payments.
Note that without pressing SAVE button, the transaction will not have any effect
Once all the approvals for the batch are completed, File will be generated. The same can be viewed
in FDTA transaction/ the same can be navigated from BNK_MONI also.
Let us consider batch 873 as an example and proceed.
Code BNK_APP. The verifier will be able to see only his batches.
In the above scenario, batch 873 alone lie
st
Click on OK to proceed, It will prompt for a transaction password:
Once it is adhered, the batch is approved by the user and passed on the First approver for his approval.
The status after verification step is as follows:
Detailed release history can be viewed using icon:
Whoever is eligible to approve this batch as per the company policy, they have to login to their inbox and
approve the batch as explained above. For app
After all the approvals are completed, the status of batch will be displayed as BATCH APPROVED.
Rejection can be done both at Batch level and Document level
Resubmit can be done only at document level.
Rejection in BNK_APP will reverse payment document automatically.
Both Reject & Resubmit can be done only by Verifier (Change and Release tab) for a new batch.
.
Double click on the batch to drill down to payment document level:
In the above batch, there are 3 payments. Assume that the first payment had some error, which needs to be
rejected. The vendor for 2
nd
payment has asked us to hold the payment for 2 more days. So only the third
needs to be processed.
To summarize, We will reject the first payment, resubmit the second and approve the third.
Select the first line item.
Press
Once this is done, press back button (F3) to come to the header screen.
Now select this batch and click approve. This means we are approving the one left over payment in this
batch.
After pressing the SAVE button, the following pop up appears:
An approver can return only the Whole batch. He cannot modify any part of a batch.
Batch returned by any level of approver (1
st
/. 2
nd
/ 3
rd
) returns the batch to Verifier for further action.
Adding attachment for reason of return of batch is mandatory
We will use batch 927 for this purpose
Select the batch and do the approval process as explained above.
Status changed to In Approval and batch is removed from the verifier screen.
By clicking on list of approvers for the batch, we get the list:
It will give the below info in the status bar:
Press back button. Another info appears in the status bar: .
This completes the Return steps. Now give the transaction password.
Now you can find the status of batch as Resubmitted by Approver and is again lying with the verifier.
Verifier can look at the attachment by selecting the batch and clicking on this icon:
Input the necessary details on the selection screen and execute the report:
Various tabs are self-explanatory.
User can sort or filter as deemed necessary. Drill down to payment level is available.
You can also drilldown into various levels by double clicking on the relevant fields to vendor master, bank
master, payment document level etc.
Few specific icons are explained here:
Icon Description
Release history/ Status history of the batch shall be checked here. For instance who created the
batch, who verified and who has approved is displayed.
Shows the approver list for the batch. User can find out with whom the batch is currently lying
for approval.
Shows the workflow attachment. For instance if the approver has provided some notes/ remarks
for returning a batch, the user can find out the remarks mentioned via this icon.
File generated for the batch shall be verified here. The user shall also download the file to local
system by navigating to the menu on this icon.
Summary of Configuration
The below table summarizes the list of configurations required for BCM functionality:
S No Activity T Code
1 Activate BCM in Switch framework customizing SWF5
2 Activate PMW for payment methods in country OBVCU
3 Maintain variant for the payment medium format OBPM4
4 Reserve Identifiers for cross-payment-run-media OBPM5
5 Bank Determination FBZP
6 Assign Company Number in DME data of House Bank FBZP
7 Basic Settings for approval in BCM SPRO
8 Payment Grouping - Rule Maintenance SPRO
9 Payment Grouping - Additional criteria for grouping SPRO
10 Map External Status to Internal Status SPRO
11 Mark Rules for automatic payments SPRO
12 Change & Release - Assign Role to release steps SPRO
13 Additional release steps - Define Release Procedure SPRO
14 Additional release steps - Assign Role to release steps SPRO
15 Assign workflow template to release procedure SPRO
16 Digital signature - specify signature method SPRO