Procurement Cards Basics : Setup and Processing
Cynthia Bruno
Philip Merlano
Michael V. Milano
Oracle Corporation
Introduction
You can streamline your procure-to-pay
process by implementing a procurement card
program in which your employees purchase
items directly from suppliers using a credit
card. The credit card issuer then sends
transaction files directly to you (the employer).
You can import credit card transaction files
from your card issuer directly into Payables.
Then, you can automatically generate
transaction accounting distributions and create
invoices to pay the card issuer. This will help
you reduce transaction costs and eliminate
low-amount invoices.
This paper walks you through the minimal
setup steps required to begin processing
Procurement Card transactions. It then
discusses the process involved in processing
the credit card input file received from your
credit card issuer.
Scope
I. Overview
II. Procurement Card Setup
III. Procurement Card Processing
IV. Troubleshooting Tips
I. OVERVIEW
1) Set up prerequisites including coding
SQL*Loader program to load Credit Card
extract files into Credit Card interface
tables.
2) Setup Credit Card information in Oracle
Payables.
3) Obtain Procurement extract file from
Credit Card company and load file into
credit card interface tables.
4) Run the Procurement Card Transaction
Validation Exception report to validate the
information that has been loaded.
5) Run the Procurement Card Workflows to
verify and/or approve the Procurement
Card transactions.
6) Run the Procurement Card Invoice
Interface Summary to transfer the
Procurement Card transaction to the
Payables Open Interface tables.
7) Run the Payables Open Interface Import to
create invoices. Approve and pay the
invoices.
II. PROCUREMENT CARD SETUP
A Procurement Card system involves issuing
numerous credit cards throughout an
organization to be used for small purchases.
The intent is to establish a large-scale petty
cash system and reduce the workload within
an Accounts Payable department.
Procurement cards should not be confused
with a corporate (travel) credit card.
Corporate (travel) credit cards usually involve
travel expenses as opposed to small purchases
using a petty cash system like Procurement
Cards.
It is not required to implement the Self-Service
Web Apps-Self-Service Employees part of
Procurement Cards to use the core
part of the Procurement Card functionality.
However, the feature was really designed to
work with the web and workflow since the big
benefit is getting the cardholders and managers
to review and approve the receipts. For
additional flexibility, your employees can use
Self-Service Web Apps-Self-Service
Employees to verify transactions and to
override default transaction accounting.
A. Prerequisites
There are a few prerequisites to setting up the
credit card program.
1) Make sure that you have the requisite
agreements in place with your card issuer.
2) Create a SQL*Loader program that uses the
flat file provided by the card issuer containing
the credit card transaction details you want to
transfer into the
AP_EXPENSE_FEED_LINES_ALL table.
For detailed information on this table and
process, refer to the Oracle Payables
Applications Technical Reference Manual and
Appendix J of the Oracle Payables User’s
Guide, Volume 2.
3) Enter your card issuer as a supplier. Include
all information including payment terms and
supplier site. If you pay with electronic
payments, enter supplier bank information.
This is done by navigating to Supplier->Entry.
4) Navigate to Employees->Enter Employees
in Oracle Payables to set up your employees
who will be cardholders. Enter complete
employee information, including employee
name, home and/or office address, supervisor,
default expense account, and cost center.
5) Assign the "Procurement Cards" and the
"Workflow" responsibilities to your employees
in System Administrator. The navigation path
is Security->User->Define.
B. Setting up a Procurement Card Program
1) Create the Credit Card Code Sets by
navigating to Setup->Credit Cards->Credit
Card Code Sets. This requires entering
Standard Industrial Classifications (SIC)
codes. You can find out more information on
these codes at
http://muse.mse.jhu.edu:8001/research/busines
s/sic.htm.
2) In the Credit Card Programs window, you
define your credit card program that includes
the card issuer, card type, and credit card code
set. In this window you also specify
transaction statuses for which you will not
create invoices. The navigation path is Setup-
>Credit Cards->Credit Card Programs.
3) You can then define GL Account Sets by
navigating to Setup->Credit Cards-
>Procurement Card->GL Account Sets. A GL
account set is a list of values that cardholders
can use to change accounts when validating
their transaction notification.
4) In the Credit Card Profiles window, you
attach the Credit Card program, assign the GL
account sets, define the default GL account,
the exception clearing account, employee
verification options, and manager approval
options. You can also restrict credit card
codes. The Credit Card Profiles form is
located in Setup->Credit Cards->Procurement
Card->Credit Card Profiles.
5) In the Credit Card window, you tie the all
previous setup steps together. You choose a
Credit Card program (which includes the
Credit Card Code Set) and a Credit Card
Profile (which includes the GL Account Set).
You also assign the card to a cardholder.
6) The predefined Credit Card Transaction
Employee Workflow and Credit Card
Transaction Manager Workflow, available
with the Self-Service Web Application, will
allow you to verify and approve credit card
transactions without customization. If you
have special processes, you need to customize
the workflows at this point. The Credit Card
Transaction Employee Workflow determines if
the employee needs to be notified and then
notifies the employee of transactions that have
been posted to their accounts. Similarly, the
Credit Card Transaction Manager Workflow
determines if the manager needs to be notified
and then notifies the employee’s manager, if
necessary. You specify whether these
notifications will be sent out on the Credit
Card Profile form.
7) If you use Self-Service Employees, you can
then configure Self-Service Employees credit
card functions using Web Applications
Dictionary. Refer to the p. 2-227 of the Oracle
Payables User’s Guide, Volume 1 for more
information.
At this point you are ready to begin processing
transactions.
III. PROCUREMENT CARD
PROCESSING
1) Procurement Card Processing begins when
you receive the Credit Card output file from
your institution. You process the output file
by running your custom SQL*Loader program
to populate the
AP_EXPENSE_FEED_LINES_ALL table.
2) The Procurement Card Transaction
Validation and Exception Report identifies
exceptions in the data such as undefined credit
card numbers, invalid transaction or posted
currency codes, and invalid credit card codes.
For records in the
AP_EXPENSE_FEED_LINES_ALL table
where the CREATE_DISTRIBUTION_FLAG
is Y, the report creates distributions with
proper accounts in the
AP_EXPENSE_FEED_DISTS_ALL table.
This program builds the default GL accounts
for the transactions based on options you
selected when setting up your credit card
programs and credit card profiles.
You can also use this report to review existing
accounting distributions for transactions that
have already been validated.
3) Once you have verified that your
transactions have successfully been validated
in the Procurement Card Transaction
Validation and Exception Report, the Credit
Card Transaction Employee Workflow is run
to determine if the employee needs to be
notified and if the employee needs to reply to
the notification. The status of the transaction,
stored in the STATUS column in the
AP_EXPENSE_FEED_LINES_ALL table,
determines if a notification needs to be sent to
the employee and/or manager. The STATUS
is contingent upon the setup of the Employee
Notification Method (ENM) and the Manager
Notification Method (MNM) on the Credit
Card Profiles form. If the ENM is set to none,
meaning the employee is not notified at all,
then the transaction will not be selected by the
process and is already set at a status to proceed
in processing. If the ENM is set to
Notification Only, the status is set during the
process of the workflow to allow it to proceed
and the employee is notified of the transaction.
If verification is required on the Credit Card
Profiles form, then the employee can set the
transaction to Hold, Personal, Disputed, or
Verified.
4) The Credit Card Transaction Manager
Workflow is used to notify a manager of
transactions if it is determined that a manager
must be notified and/or a manager must
approve the transaction. If the MNM is set to
None or Notification Only, then the status of a
Verified transaction is automatically set to
Approved. If Manager Approval is required,
then the manager sets the transaction status to
either Approved or Rejected.
5) Use the Credit Card Transactions window
to review and update credit card transaction
distributions. When you load transactions
from the card issuer, each transaction has one
distribution. You can use this window to split
a transaction distribution into multiple
distributions which you can process separately.
For example, an employee receives a bill for a
ream of paper. Instead of charging the $100
discount rate, the supplier is charged $130.
You can create two distributions for the
transaction, one for $100, and one for $30.
You can assign a status of Disputed for the
$30 transaction and process the $100
distribution as usual. To prevent payment of a
transaction distribution with a status of
Disputed, you also need to check the Disputed
checkbox in the Don't Pay If Status region of
the Credit Card Programs window.
6) After the employees and managers verify
and approve the transactions, you submit the
Procurement Card Invoice Interface Summary
to import the data into the Payables Open
Interface tables and optionally summarize the
data by GL Account (CCID). This program
creates invoices for your credit card issuers in
the Payables Open Interface tables. This
program selects all records for a given date
range in AP_EXPENSE_FEED_DISTS with a
status of at least Validated, i.e. the transaction
has gone through the employee and manager
workflow successfully. It populates the
payables open interface tables,
AP_INVOICES_INTERFACE and
AP_INVOICE_LINES_INTERFACE. These
tables are read by the Payables Open Interface
Import, which creates invoices from these
records. The Invoice Interface Summary
program will not select any statuses that you
have specifically excluded from payment in
the Credit Card Programs window. Also, the
program will not select any records that have
been previously selected by the program. If
you choose to summarize the transactions, the
system will create a single invoice for each
unique CCID and Tax Name combination. In
addition, if you summarize the transactions,
the report will display only the Line, Account,
and Amount.
7) You can then submit the Payables Open
Interface Import Program to create invoices
from the data. The invoices are ready for
accounts payable approval and payment.
Note: To obtain this functionality for release
11.03, you must apply patch 934168.
IV. Troubleshooting Tips
Prob: The Procurement Card Transaction
Validation Report does not show exceptions.
Sol: You may need to apply patches 817026,
914049 which are prerequisites patches for the
Self-Service 11.03B patch (914049).
Prob: You want to purge Procurement
Card records in the
AP_EXPENSE_FEED_LINES_ALL table.
Sol: Currently there is no Procurement Card
Purge for records stored in the
AP_EXPENSE_FEED_LINES_ALL table.
Prob: With regard to entering credit card
numbers, the validation reports will not
pick up credit card numbers unless spaces
are used as delimiters.
Sol: Use spaces as a delimiter, for example:
5500 6600 7700 6205.
Prob: The Procurement Card Transaction
Validation report does not have the correct
Count and Total on the report.
Sol: In order to get a correct Count and Total
on the Procurement Card Transaction
Validation Report, you must populate a unique
the reference number.

Prob: The Procurement Card Transaction

Validation fails with the following
information in the log file:

MSG-00200: Calling Validation API

REP-1419: 'beforereport': PL/SQL
program aborted

Sol: Navigate to Credit Cards -> Credit Cards

in Oracle Payables.

The Card Number must be unique for each

employee.

About the Authors

Cynthia Bruno is a Technical Analyst with the

Oracle Support Financials group. She has
been working for Oracle Support for over a
year.

Philip Merlano is a Senior Technical Analyst

with the Oracle Support Financials group. He
has been working for Oracle Support for 2
years.

Michael Milano is a Technical Analyst with

the Oracle Support Financials group. He has
been working for Oracle Support for 2 years.