Credit Card Processing Suggestions

In vanilla Release 10.7 there is no direct handling of credit card activity.

When you enter an order in Oracle Order Entry, you can indicate:

the type of credit card

the expiration date

the credit card number

the authorization code (if used).

All of this information is purely informational and none on this information is passed to Oracle Receivables.

In order to add to the functionality that is available you need to determine the following:

1) What is the level of detail that you need in Oracle Receivables?

- individual invoices?

- payment history?

2) What information will you receive from your credit card processor?

My experience is that this information is minimal at best.

- customer name?

- customer number?

- ‘receipt’ number?

- receipt amount?

- invoice(s) paid?

- amount paid for each?

3) Can you make the assumption that if an order has been shipped, the credit card has been authorized and you will get the money?

4) Also, are there charges such as freight and tax that are added after the order is entered? This may cause the total amount to be invoiced to be different than the amount that was quoted to the customer (and potentially entered into the credit card system)!

5) Could you have partial shipments against a single order? If yes, how much will you charge against the credit card? When initially ordered? When partially shipped? How will you handle this?

6) What will you do if a product is returned or the customer wants a credit against their credit card? How will you handle this procedurally? What do you want the system to do?

You have several options depending on your answers to these questions:

Regarding questions 4, 5 and 6 - these will need to dealt with procedurally as part of your order processing.

Payment Details Not Needed

If you do not need payment details for the invoices, you have the simplest solution:

Create a special Transaction Type for these transactions that has Post to GL as Yes (checked) but Create an Open Receivable as No (not checked). This will cause the individual invoices to be created but they will never appear on the aging and will automatically be closed as part of this process. You do however, have an audit trail of what was "invoiced". It is up to you whether you print these invoices and send them to the customers or not.

If you track your activity (and use different GL accounts) by Credit Card type (e.g., Visa, Master Card…) you will need to setup special Transaction Types for each.

Your next issue is how to account for the receipts. You have 2 options: 1) create a manual journal entry (in GL) by bank for the amount actually received (by credit card type) as indicated by the bank. Debit the applicable Cash account and Credit the applicable AR accounts ( I personally hate any use of manual journal entries). The advantage of this option is that you only account for the amount of money actually received from the bank, but what do you do when it is not a wash?

Another option is to define the special Transaction Types to Debit the appropriate cash account and Credit the applicable revenue account. This automatically takes care of accounting for the cash and the revenue and bypasses the step of Debiting and then Crediting your AR account. The only disadvantage of this option is that it assumes that you will always be paid in full for all credit card receipts. Again you need to check this with what the bank said you actually received and decide what you will do if they are different.

Payment Details Needed

If you would like to see the payment details you also have options. First, if you can receive the details listed in question 2, you can simply load that data into the system using AutoLockbox. The advantage of this approach is that you only apply payment to those items where you have really received payment. The issue may be getting the details you need from the credit card company.

Another approach is to have the Cash Appliers manually enter the payments against the open invoices based on the "slips" created from the credit card machines. This assumes that you at least have a procedure in place to write the order number on each ‘slip’ as they are created. This can be quite time consuming and the appliers would have to query on the Order Number first to see which invoices apply to which open invoices. There is also the issue of partial shipments against an single order.

The approach that I have used, is to create a script to create "dummy payments" for any credit card transactions. This process runs after the last AutoInvoice process (to get the latest transactions) and creates data to run through the AutoLockbox process.

- it queries all transactions that have credit card terms and which have open balances

- since the transaction has the order number, the script uses it to get the credit card information from the related order

- it creates one receipt per invoice using the balance due as the amount

- it derives a check number usually as some combination of the type of credit card and the invoice number e.g., MC-1233456 (for security reasons I don’t suggest using the full credit card number, this number is too visible)

- the receipt date is the date the credit card was processed

- since you know the customer from the transaction, the script can also provide the customer number

- the script creates batches by credit card type

The output is a flat file that can then be loaded and processed through AutoLockbox.

Advantage, you have an audit trail of what was paid. The disadvantage is that you will be out of sync what was actually charged against the credit card if there was a partial shipment or additional charges.

Related Setups

No matter which option you choose to use, you will need to create the related setups:

Set up one payment term for each credit card type. These values should be used by Oracle Order Entry when entering the order.

Set up at least one Transaction Type per credit card type. You may need to set up more Transaction Types if you use multiple AR accounts within credit card type. These Types should be set up with the proper options for Post to GL and Create an Open Receivable (based on the option you are using).

AutoAccounting

Insure that your setups allow for attaining the AR information from the Transaction Type and that it will really work to provide you with the Cash account, if that is the option you choose.

Again no matter which option you choose, you still have the issue of passing the proper Transaction Type to Oracle Receivables. Vanilla Oracle Order Entry allows you to assign a single Transaction Type to each Order Type. Since you cannot change the Order Type once you have created the order, without canceling and re-entering the order, it is desirable to use a minimal number of Order Types. Since we want to separate transactions by credit card type, we want to use multiple Transaction Types.

The way that I have gotten past this problem is to create a script that updates the Transaction Type, after the Receivables Interface and before AutoInvoice. This script can use information such as Payment Terms (since they are setup by credit card type) to determine what the proper Transaction Type should be.

Conclusion

As you can see, you have various options available. You just need to decide what you need and the decisions should be easy.