You are on page 1of 17

Oracle iProcurement: P-Card

Functional Setup
An Oracle White Paper
August 2000
Revised October 2002

Oracle iProcurement: P-Card


Functional Setup

ABSTRACT

The Oracle iProcurement (IP) product enables corporations to acquire goods and
services through the Internet. A procurement card (P-Card) is a corporate credit
card issued to an employee to purchase items directly from a supplier.
P-Card orders are approved and transmitted to the supplier like any other order.
When you order an item, the Billing page (or Order Information page, if you are
using Power Checkout) lets you select a P-Card number if you have one. PCards must be set up for each employee. You cannot enter a number yourself. If
a P-Card is set up for you, you will see your P-Card number in the pull-down PCard Number menu on the Billing page (or Order Information page) when you
place an order.
CONTENTS

1) Oracle Application Modules Needed for P-Card Functionality


2) Supplier Setup
3) P-Card Program Setup
4) Credit Card Setup
5) Requisition Creation in iProcurement Using P-Card
6) P-Card Validation
7) Encumbrance and Receiving for P-Card transactions.
8) Features included in 10.7, 11.0.3 and 11i
9) Known Issues and Resolutions
Oracle Application Modules Needed for P-Card Functionality

You will need to implement a combination of several Oracle Applications


modules (e.g. Oracle Purchasing, Accounts Payable, General Ledger, etc.).
iProcurement is the core module of the procurement process. For P-Card
purchase orders, the Invoice Match option on the Shipment form should be
disabled with a Null value. P-Card purchase orders cannot be matched to
invoices or receipts. Make sure to set up Suppliers as P-Card enabled suppliers.

Supplier Setup

Set up your supplier and P-Card enabled suppliers sites. The P-Card check box
that enables P-Card use appears in the core Purchasing application under Supply
Base Suppliers. Select a supplier site by clicking the Site button in the lower
right hand corner of the Supplier screen. The P-Card checkbox appears in the
General region on the supplier site screen.
Fig. 1: Supplier Setup

Fig. 2: P-Card Supplier Site Setup

P-Card Program Setup

Set up your supplier card program, profile, code sets and cards as described
below. In the following P-Card examples, employee name Nag Dasari
(NDASARI) is the buyer.
1. Card Brand: Oracle Express
Expiration Date: 10-June-XXXX
Requisition Transaction Limit: $1000.00
Card number: 3997-4567-1111-3212

Card Brand: Oracle Express


Expiration Date: 10-Aug-XXXX
Requisition Transaction Limit: $5000.00
Card number: 3123-4561-2222-7892
Credit Card Setup

1. In the Credit Card Code Sets window, create credit card code sets. Enter
card codes, such as Standard Industry Classification (SIC) codes, or
Merchant Category Codes (MCC). Assign a default GL account to a card
code.

Fig 3: Credit Card Setup

Fig 4: P-Card association with


Employee and Supplier and setting up of
Maximum and Minimum amount transactions

2. In the Credit Card Programs window, define your credit card program,
including the card issuer, card type, and credit card code set. In this
window you can also specify transaction statuses for which you will not
create invoice.
3. In the Credit Card GL Sets window, define GL account sets. A GL account
set is a list of values that cardholders can use to change accounts during
transaction verification.
4. In the Credit Card Profiles window, define credit card profiles that you
assign to credit cards. Attributes of a credit card profile include credit card
program, GL account set, default GL account, exception clearing account,
employee verification options, and manager approval options. In addition
you can record restrictions for credit card codes.
Fig 5: Setup of Credit Card Profiles

5. In the Credit Cards window, assign a card to a cardholder and assign a credit
card profile to the card.
6. Set up the Credit Card Transaction Employee Workflow.
7. Set up the Credit Card Transaction Manager Workflow.
8. In the Users window, assign a Credit Cards responsibility and the Workflow
responsibility to employees.

There are four levels of the Credit Cards responsibility that you can define
for employees:
1. Credit Cards - Assign this responsibility for employees that should have
access to records for one or more employees. The securing attribute for the
seeded Credit Cards responsibility is ICX_HR_PERSON_ID. To allow a
Web user the ability to verify open credit card transactions and to review a
credit card transaction history for more than one employee, define an
additional securing attribute value (ICX_HR_PERSON_ID).
2. Credit Cards (Card Profile Administrator) - Assign this responsibility for
the employee that is the Administrator in the Credit Card Profiles window.
This responsibility has access to all records for a Credit Card Profile.
Attention: To assign this responsibility, you must first define the employee
name for Administrator in the Credit Card Profiles window. You must also
define the Securing Attribute in the Users window to
AP_CARD_PROFILE_ADMIN_ID. You then assign the EMPLOYEE_ID
for the profile administrator as the Securing Attribute Value.
3. Credit Cards (Program Administrator) - Assign this responsibility for the
employee that is the Administrator in the Credit Card Programs window.
This responsibility has access to all records for a Credit Card Program.
Attention: To assign this responsibility, you must first define the employee
name for Administrator in the Credit Card Programs window. You must also
define the Securing Attribute in the Users window to
AP_CARD_PROGRAM_ADMIN_ID. You then assign the EMPLOYEE_ID
for the program administrator as the Securing Attribute Value.
Verify Open Transaction. Use to update the status, cost center, account, and
description of a transaction. You can also split a transaction.
View Transaction History - Use to review a transaction history. The seeded
Workflow responsibility includes the following functions:
4. View Notifications - View notifications sent by Workflow.
View Progress: View the progress of the workflow process for a selected
document. The securing attribute for the seeded Workflow responsibility is
ICX_HR_PERSON_ID.

Creating a Requisition using P-Card in iProcurement (SSP 5)


Oracle Self-Service Purchasing automatically flags shopping cart lines for
Procurement Card (P-Card) payment and defaults in the P-Card number
depending on requester and supplier profiles. After an internal order has
been created and approved, a P-Card order is generated and transmitted to
the supplier. The supplier then transmits P-Card information to the card
issuer who, in turn, sends a consolidated statement comprised of transaction
data to Accounts Payable.
Fig 6: iProcurement (SSP 5) Homepage

Billing Information of P-Card

Make sure the drop down list shows the last 4-digits of the P-Card
associated to the employee. Oracle Self-Service Purchasing allows the user
to optionally specify a status of Taxable or Tax-Exempt (see fig. 8) for the
requested item (overriding the system-determined default value). The status
indicated on the requesters order line is carried forward to the purchasing
document that is created from the requesters order.
Fig 7: Billing Information showing
P-Card being billed for the
corresponding transaction

Validation

The following screen shows the warning when the transaction exceeds the
amount limit associated with the P-Card.
Fig 8: Validation of the amount limit for P-Card transaction

Encumbrance and Receiving for P-Card transactions


The procurement card information itself is transmitted to the supplier
through eCommerce Gateway, through the outbound purchase order
transaction. Upon receiving the purchase order, the supplier transmits the
procurement card information to the procurement card issuer (for example, a
bank). The credit card issuer then sends transaction files back to Oracle
Payables, which automatically generates accounting distributions and
creates invoices to pay the issuer.
If a supplier rejects a procurement card order, the buyer can notify the
requester of the rejection. The buyer can cancel the purchase order and ask
the requester to resubmit the requisition, or resend the purchase order using
a different form of payment.

Procurement card purchase orders and releases can be created only from
requisition lines in iProcurement. To use procurement card purchase orders
or releases in Purchasing, you must set up procurement card functionality in
both iProcurement and Payables.
Procurement card purchase orders:
Cannot be used with encumbrance accounting.
Can be used for items with a Destination Type of Expense only.
Cannot be used for documents that contain a Project number.
Can be used for standard purchase orders or releases only.
Are not available for invoice matching or invoice creation.
Do not accrue on receipt.
Receiving
You receive a procurement card order like any other. However,
procurement card items do not accrue upon receipt. Payment and
accounting for procurement card orders are already handled in
Payables, which imports the credit card transaction files from the credit
card issuer. If you accrue upon receipt, Purchasing accrues upon
receipt all items except procurement card items. You cannot change the
Accrue at Receipt check box in the Shipments window for procurement
card purchase orders or releases.
Similarly, at periodend, Purchasing does not accrue or roll over
procurement card orders to General Ledger.
Invoicing
Since invoices for procurement card purchase orders are created through
credit card transaction files that are imported from the credit card issuer into
Payables, note the following:
Procurement card purchase orders are not available for invoice matching in
Payables.
Procurement card shipment lines are automatically closed after approval if
you use the TwoWay match approval level. (If you use ThreeWay or
FourWay match approval levels, you can still receive or inspect against the
shipment.)
Payment on Receipt does not generate invoices automatically for
procurement card orders, even if the supplier is set up as a Pay on Receipt
site in the Supplier Sites window. A supplier site can be both a Pay on
Receipt site and a Procurement Card Site. However, if the supplier site is
a Pay on Receipt site, invoices will be generated automatically for all orders
received from that supplier site when you run Payment on Receipt, except
those that include procurement card information.

Advance Shipment Notices (ASNs) that contain billing information


(sometimes known as Advance Shipment and Billing Notices, or ASBNs), if
they also contain procurement card information, are not automatically
converted into invoices as they normally would be upon receipt.

10

Features included in 10.7, 11.0.3 and 11i :

Features
10.7
User Preferences
Available
Changing your password
-Direct sign-on
-Non-catalog requests
Available
Personal Favorites List
Available
Corporate/Public shopping
Available
Lists
Special Item Information
Available
Saving Shopping Carts
Available
Power Checkout
Available
Express Checkout
Available
Regular Checkout
Available
Checkout Defaults
Available
One-Time address
Available
Default Deliver-to location
Available
Inventory Replenishment
Available
Requests
Procurement Card support (P-Card)
Integration with Project
Available
Accounting
Integration with Project
-Manufacturing
Attachments
Available
Mass Updates
Available
Account Generation
-Workflow Integration
Requisition Approval
Available
Workflow
Confirm Receipts Workflow
Available
Autocreating standard PO
-from Contracts
Multiple Account
Available
Distributions

11
Available
Available
Available
Available
Available

11i
Available
Available
Available
Available
Available

Available Available
Available
Available
Available
Available
Available
Available
Available
Available

Available
Available
Available
Available
Available
Available
Available
Available

Available Available
Available Available
Available Available
Available Available
Available Available
Available Available
Available Available
Available Available
Available Available
Available Available
Available Available

11

Approval List Configuration


Finding Requisitions to
Approve
Editing requisitions in
approval queue
Vacation handling/reassigning
to-do notifications
Copy Requisition
Requisition Cancellations
Requisition resubmit
Requisition withdraw
Emergency Requisitions
Requisition status (Inquiries)
Centralized Receiving Home
Page
Receipts inquiry (history)
Finding Items to Receive
Returns and Corrections
Upload catalogs
Download templates
Building Table of Contents
Mapping Categories
Mapping Special Order
Catalog Search
Comparing Catalog items
Linkout to
Suppliers/Marketplaces
E-Content Manager (Catalog
authoring tool)
Retrieve Forgotten Password
Multi Byte Language
Search Based Punchout
OU Specific Purchasing News
and Policies
MLS Compliant Loader
Dynamic Templates for
Spreadsheets

Available

Available Available

Available

Available Available

Available

Available Available

Available

Available Available

Available
Available
Available
--Available

Available
Available
Available
Available
Available
Available

Available

Available Available

Available
Available
-Available
Available
Available
Available
Available
Available
Available

Available
Available
Available
Available
Available
Available
Available
Available
Available
Available

Available

Available Available

Available

Available Available

--Available

Available Available
Available Available
Available Available

Available

Available Available

---

--

Available
Available
Available
Available
Available
Available

Available
Available
Available
Available
Available
Available
Available
Available
Available
Available

Available

Available Available

12

Suggested Buyer
Hazard Information
Express Receiving
iHelp Integration
New Punchout Architecture
Express (employee/location)
Loader
Global Supervisor
Transaction Currency
Improved Search
Expense Account Exception
Rules
Direct Approve and Reject
Estimated Tax
Favorite Charge Accounts
Contract Autosourcing
Grants Support
Enhanced Global Buyer
Defaulting

------

------

Available
Available
Available
Available
Available

--

--

Available

----

----

Available
Available
Available

--

--

Available

------

------

Available
Available
Available
Available
Available

--

--

Available

Known Issues

In iProcurement, you created a procurement card with a transaction amount


for a specific user. However, when creating a requisition in iProcurement
with the P-Card established in the core application, the requisition submittal
process never validates against the P-Card limit. A requisition that exceeds
the amount of the P-Card completes without error.
Solution:
--------Make sure the profile used for the P-Card has the Time Unit field set to
TRANSACTION:
A. From the AP Superuser responsibility, navigate to set up credit cards and
procurement card profiles.
B. Query the profile attached to your credit card. The maximum amount
field will only be validated on a requisition in Self-Service Purchasing if the
value is TRANSACTION.
C. On the list of values itself, scroll up to find the correct value. On some
forms only PERIOD and MONTHLY are displayed. By scrolling up you
will find the other codes. The actual code that performs this validation is
contained within the ReqHeader.java file as follows:

13

String sqlStatement = "SELECT apcl.amount " +


"FROM ap_card_profile_limits apcl, " +" ap_cards apc " +
"WHERE apcl.profile_id = apc.profile_id" +" AND
apcl.time_unit_lookup_code = TRANSACTION'" + " AND apc.card_id = ?";
1. Entering a Purchase Order in the Purchase Order Entry Form
(POXPOEPO), the field P-Card Number is visible and accessible even
though you do not want to use the Procurement Card functionality. The PCard Number field is also appearing in the Purchase Order Summary Form
(POXPOVPO). This problem will only be encountered using release 11 of
the applications or higher.
Solution:
--------There is a profile option 'PO: Use P-Cards in Purchasing' which exists only
for release 11 or higher. When this profile option is set to 'Yes' the
Procurement Card functionality will be enabled and the Procurement Card
Number fields will appear on the two forms. Setting this profile option to
'No' will ensure that the Procurement Card functionality is disabled and the
Procurement Card Number field does not appear on the Purchase Order
Entry and Summary Forms.
2. Can the Supplier/Site for a P-Card enabled PO be changed?
Steps to recreate:
------------------a. Enter a non-catalog requisition with supplier and site.
(supplier > site > enabled for p-card)
b. Use p-card during checkout.
c. Buyer auto-creates from core purchasing and changes the supplier
and site (that is not enabled for P-card).
d. The p-card field still holds the p-card number even the supplier
and site are not enabled for p-card

Trying to change manually the field Error is raised field is protected


against update.
Analysis
---------Currently for a requisition line with an associated p-card, during the auto
create process, the buyer is able to change the supplier/supplier site
information. The Autocreate form restricts the change only to other p-card
enabled supplier/supplier sites (i.e. LOV for the supplier/supplier site field
shows only p-card enabled supplier/supplier sites). So the p-card
information will always apply for the supplier/supplier site on the resulting
PO document.
There is a problem on the PO Entry form (after the PO gets created) in that
there is no similar restriction on the supplier/supplier site field. So the buyer
can change it to any other supplier/supplier site, and the p-card information

14

remains on the PO even if the newly selected supplier/supplier site is not pcard enabled.
Solution: This bug is addressed and fixed in Procurement Family Pack H
(R11i.PRC_PF.H patch #2320032, R11.0.PO.H patch #1618257)
3. When a Credit Card inactive date in the Payables: Credit Cards form is
populated with a future date, the P-Card information is no longer visible
in the SSP5 billing information.

Solution:
--------Fixed in ReqHeader.java 110.65, 115.36, available in ICX Patchset F.
(R11.0.PO.F patch #1330514) Bug 1341092
Summary

One of the most important aspects of the Distribution/Supply chain is the ability
to procure goods and services. iProcurement replaces the typical manual
procurement process with a streamlined, decentralized, electronic commerce
process that can dramatically reduce costs and time involved in doing so. P-Card
functionality gives an added advantage for procurement and receiving items with
P-Card transactions.

About The Author

Nag Dasari is a Senior Technical Analyst for E-Business Outsourcing Support


with Oracle Corporation in Orlando, Florida. He has M.S. and B.S. Degrees in
Computer Science and Engineering and has over 10 years of software industry
experience in Managing Oracle ERP applications, design/development, QA, and
in Supporting Oracle Applications.
Credits

Oracle Purchasing Users Guide.


Oracle Payables Users Guide.
Oracle Self-Service Purchasing Implementation Manual
Oracle Product Management/Development/Support Team who were
instrumental in identifying the issues and releasing fixes.

15

Oracle iProcurement: P-Card Functional Setup


August 2000
Updated: August 2002
Author: Nag Dasari
Contributing Authors: n/a
Copyright Oracle Corporation 2000
All Rights Reserved Printed in the U.S.A.
This document is provided for informational purposes
only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.
Oracle is a registered trademark of Oracle Corporation.

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
650.506.7000
Fax 650.506.7200
Copyright Oracle Corporation 2000
All Rights Reserved

16

You might also like