I guess all of us would agree that the world has realized an electronic form of money in terms of credit cards. Today there are plenty of banks which of offer a variety of credit cards to their customers to increase the purchasing power thus promoting better trades.
The objective of this blog is to highlight the use of corporate credit cards used in a business environment and from a technology perspective how SAP is going to play a very crucial role in automating the credit card process. It's also important to know how the accounting entries are treated in a credit card process differently compared to a standard order-delivery-invoice-accounting scenario. I will try to highlight the importance of SAP NetWeaver technology in providing the Enterprise Services.
To implement online credit card processing in SAP we need an interfacing with the 3rd party vendors. We use the SAP Net Weaver's PI and J2EE engine which provides the required communication medium.
Benefits of automating credit card processing in SAP
a) It improves cash flow by reducing the outstanding receivables since the chance of defaulting/not making payment in time is reduced.
b) The transaction efficiency is highly increased since for every sale made through credit card process is almost sure to be realized.
c) Can even reduce the paper invoicing costs.
d) Better vision of the incoming receivables so that the business can plan its future plans accordingly.
Terminology associated with credit card processing
a) Merchant ID- It's the ID given by the merchant bank to the supplier to which the payments and collections are affected.
b) Merchant Bank - Supplier's Bank i.e. the company which is implementing credit card process.
c) 3rd Party Service Provider - It provides the interfacing between SAP and clearing house.
d) Clearing House - Provides the authorization and settlement services.
e) Authorization - The process of checking whether the credit card is valid or not and enough fund is available to make a purchase.
e) Authorization Window* - It's the number days that you want to consider the material as available and execute an authorization.
f) Authorization Validity - It's the number of days an authorization is valid within which the complete order-delivery-billing-accounting and settlement process should be completed. If the authorization validity expires, a new authorization is required to be made to complete the remaining transaction process.
g) Settlement - The process of collecting the fund blocked on the credit card of customer during authorization when a purchase was made.
Data Flow in SAP
R/3 --> PI --> 3rd Party Service Provider --> Clearning House
Upon receiving a customer purchase order we start creating a sales order in SAP.
After entering the sales order information like sold to, ship to, material, quantity for a given sales area, we select from the sales order menu GoTo > Header > Payment Cards.
Here we need to enter the card holder information like card type, card number, valid to date and the card holder name. We can even fill the additional fields like CVV number and CVV usage status for implementing additional checks.
Now the system checks the material availability date on the sales order overview screen > shipping tab whether it's falling into the authorization window* or not.
So after the all the required information on the sales order is filled, we click the save button which triggers the authorization function module. It takes the card holder information along with the material ordered, quantity, price and goes to the PI server. At the PI server a web service part of the J2EE engine is invoked to establish a connection with the 3rd party service provider who gets the clearing house service for authorization. Since we are using the web service in our enterprise to call different systems identified as services, it's making use of the enterprise service oriented architecture.
We can have three possibilities for a response from clearing house:
- a) Successful authorization which indicates that the card holder data is valid and there is required amount of fund on the card.
The sales order is successfully saved with a valid authorization. Now this portion of the fund is blocked on the customer's credit card for the authorization validity period. This means before the authorization validity is expired we need to ship the goods, do invoice and make settlement.
- b) The authorization is declined since the card is not valid or does not have enough funds to buy.
An authorization block is set to the set sales order and hence further processing can't be carried out. The credit card order goes into a credit hold which can be processed at a later stage for reauthorization after checking with the customer that the card can now be tried again. There is also a manual option to remove the credit hold through VCC1 transaction; it's similar to VKM1/VKM3 used for releasing standard orders from credit hold. But we should not attempt to use VKM1/VKM3 for releasing credit card orders since they can create a delivery but cant post the goods issue later since they don't have a valid authorization on them. We have managed this difficulty by removing authorization of end users to use VKM1 for releasing credit card orders. Also we have changed the report layout of VKM1 to distinguish credit card orders separately.
- c) The 3rd party service is temporarily unavailable so we need send the data again to try the authorization later.
The re authorization program which can be scheduled per a batch job runs at a given frequency and tries attempt for authorization at a later stage.
Finally after successful authorization we process the delivery/picking/packing and PGI. The shippable items after PGI are processed for invoicing. As soon as the invoice is saved an accounting document is created where the customer account shows as cleared. That's the main difference in accounting in credit card processing. The reason being, we are sure collect the fund as we have already blocked it during authorization. So we clear the customer account and debit an interim credit card settlement account.
Now we go for the actual settlement of the accounting document posted through FCC1 transaction. Settlement is the process where we try to collect the fund blocked during authorization into our merchant bank. As soon as the settlement transaction FCC1 is executed, a settlement function module triggers and sends the data to PI server. From here a web service is again invoked to contact our 3rd party service provider for settlement.
After successful settlement, the interim credit card settlement account is credited and the main credit card clearing account is debited. This is also reflected at GL account line item display at FBL5N.
Incase of a failed settlement, the credit card settlement account is reversed by FBRC - (reverse posting) transaction which is embedded into the settlement function module. But the customer account would continue to show as cleared. I guess it's a bug in SAP for which we are still trying to find a solution. The process is finally completed by re attempting settlement with FCC2 (Repeat Settlement) transaction.
I shall try to discuss some of the implementation issues, security guidelines in my future blogs.
