August 24th, 2007
Up to 11.5.9, it was impossible to utilize the credit card functionality and secure fields unless you also implemented iPayment. Oracle iPayment is the module which screens and processes credit card transactions through Order Management (OM). While this is a nice package for clients who process high volumes of credit card payments, it’s not cost effective for the rest who may process credit cards on occasion and prefer to use an offline processor. So at the time you had two options; either fork up the money to buy the iPayment module, or process and store the transactional information offline and enter the prepayment manually in the system.
However, as of recently, Oracle has offered a patch (5192725) which allows for the use of the credit card fields in OM without the need to install iPayment. The application of this patch alone is not enough, as there are other tweaks that need to take place to make it all work. At any rate, I take this as a great act of generosity on Oracle’s part – it’s not often they provide us the choice to implement a module!
The first step (of course) is to apply the patch. If you look up the patch in Metalink the given description is kind of hazy, but this was the patch recommended to me by Oracle. It appears to incorporate several fixes for Family Pack J. As with any patch, be sure to thoroughly test the patch first before applying to your production instance.
Next, we need to create our receipt class in AR which will classify the receipts that are generated from processing a credit card payment in OM. To do this navigate to the appropriate AR responsibility, than Setup > Receipts > Receipt Classes.
To start, let’s name our receipt class “Credit Card”, since this receipt class will be used specifically for receiving credit card prepayments. Additionally, we’ll want to specify “Automatic” to indicate this will be an automatic transaction that will be generated from OM.
As you continue entering the other key information, the most important field to note is the “Payment Type” field located under the “Automatic” tab. Prior to the introduction of this patch, we would select a type of “Credit Card” in order to enable the use of the credit card functionality with iPayment. But for our purposes, leave this field BLANK. With the application of patch 5192725, this is now the key indicator which will tell the credit card processor in OM to avoid making any calls to the iPayment module.
Once you have saved your “Credit Card” receipt class, you can continue with the remaining AR setups that are standard to any receipt class; most notably, the document sequence (which should be set to Automatic) and your receivables activity.
To do this, you’ll need access to Application Developer to open the profile definition. After logging into this responsibility, navigate to NAVIGATION_PATH and query for the “OM: Payment Method For Credit Card Transactions” profile. Upon opening the responsibility, you’ll notice a SQL validation section. Copy and paste the below code into this box:
SQL=”SELECT NAME \”Receipt Method\”
WHERE SYSDATE >= NVL( START_DATE, SYSDATE )
AND SYSDATE <= NVL( END_DATE,SYSDATE)
AND (PAYMENT_TYPE_CODE IN (’CREDIT_CARD’,'NONE’)
OR PAYMENT_TYPE_CODE IS NULL)
Notice the above SQL opens up the restriction so that the profile will allow both “Credit Card” and “None” types of payments. After pasting the code, save your changes, and navigate to your System Administrator responsibility (if you happen to be so lucky) and set the “OM: Payment Method For Credit Card Transactions” profile to our receipt class.
Now we’re in business! Let’s test our solutionâ€¦
To start, enter a sales order header with data you have handy. In the “Others” tab, the key fields to note are:
- Payment Term – make sure this is set to a term setup for prepayment. If not, revert back to your OM setups to ensure a prepayment term is established.
- Payment Type – this will be entered as “Credit Card”
- Credit Card Number
- Card Holder
- Card Expiration Date
- Approval Code – this should be the approval code issued by your 3rd party processor upon successful confirmation of the card
Notice that when you’re entering the credit card number that it’s fully visible. Depending upon how you’ve setup the credit card number encryption, this data will save and be replaced by ‘*’’s for extra security. It’s important that you communicate to your users that before saving this information that they must perform there offline processing so that they can reference the full credit card number!
The offline credit card processor typically provides an approval code which indicates the credit card screening was successful. Enter this approval code into the “Approval Code” field. Otherwise, in the situation where the credit card has failed, you can leave this field blank and the order will be automatically placed on “Prepayment Hold” which will prevent further processing of the order until the transaction is revisited and the hold is released.
After performing the offline processing, you can than proceed with entering your order lines, again, using test data you have handy.
After completing order line entry, it’s now time to put our solution to the test! Upon booking the order, Order Management will interface a prepayment receivable in AR indicated that the sales order has been prepaid. Results of this activity can be evaluated in the Order Messages window that appears after clicking the “Book” button. If you see a message stating “Receipt number XXX has been processed”, your test was a success!
Your next step is to revert back to Accounts Receivable to verify the receipt is complete and generates the proper accounting. Aside from this validation, you’re now in the position to capture credit card information in Order Management and process offline -without the need of iPayment!