Procurement Card 2p202m

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 ing 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. II. III. IV.

Overview Procurement Card Setup Procurement Card Processing 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 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 s 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 transactions and to override default transaction ing. 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 ’s Guide, Volume 2. 3) Enter your card issuer as a supplier. Include all information including payment 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 , and cost center. 5) Assign the "Procurement Cards" and the "Workflow" responsibilities to your employees in System . The navigation path is Security->->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 Sets by navigating to Setup->Credit Cards>Procurement Card->GL Sets. A GL set is a list of values that cardholders can use to change s when validating their transaction notification. 4) In the Credit Card Profiles window, you attach the Credit Card program, assign the GL sets, define the default GL , the exception clearing , 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 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 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 s. 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 ’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 s in the AP_EXPENSE_FEED_DISTS_ALL table.

This program builds the default GL s 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 ing 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 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 (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, , and Amount. 7) You can then submit the Payables Open Interface Import Program to create invoices from the data. The invoices are ready for s 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 Financials group. She has been working for Oracle for over a year. Philip Merlano is a Senior Technical Analyst with the Oracle Financials group. He has been working for Oracle for 2 years. Michael Milano is a Technical Analyst with the Oracle Financials group. He has been working for Oracle for 2 years.