Oracle applications - Surendranath Subramani: December 2014

Thursday, December 11, 2014

Oracle Credit card and Pcard process

Credit Process:

Applicable for r12:

Setup:

1.       Create card program

While defining card program (card issuer) make sure card type is chosen has ‘TRAVEL’
Payment due from “Both” this is required to choose.
There are 3 types available:

Individual – payments are always made to employee through iexpense

Bank sends credit transactions, employee load the transaction in iexpense and complete the expense process, once approved employee is paid from employer

Both – 2 payments are made. 1 towards card issuer for all business expenses and other is done to employee.

Bank sends credit transactions, employee load the transaction in iexpense (it should be chosen as business purpose for all business related expense) employee can create personal expenses along with same expense report and send for approval. Once approved employer pays personal expense to employee and business expense to card issuer.

Note: in both individual and both pay method employee is liable to pay to bank.

Company – payments are always made to card issuer through iexpense.

Run 'Create Credit Card Issuer Invoice' this program will issue invoice to credit issuer

Bank send credit transaction and for business transaction employer will pay directly to bank without importing in iexpense for other transaction employee create expense report and get them reimbursed. 
























Credit process overview:

a.       Once bank send the file, pick the file using custom program or (use standard program if US Banks/AMEX) and load data to AP_CREDIT_CARD_TRXNS_ALL table
b.      'Credit Card Transactions Validation Program' will validate the loaded transaction.
c.       Login to iexpense
d.      Create new expense report; you have option to import credit transaction what was loaded earlier.
e.      Once submitted and approved new expense report will be created with same expense report name ||.1 (this will pay to card issuer) – this is applicable for payment_due_from_code  = both.
f.        'Expense Report Export' program will issue invoice to employee and bank (create invoice in AP_INVOICES_all table)
a.       Run 'Create Credit Card Issuer Invoice' this program will issue invoice to credit issuer. provided payment_due_from_code='COMPANY'
g.       If AP approval has been setup then approval process is initiated and once fully approved invoice will be ready for payment.

h.      Card ID is mandatory for interface table.
i.         Interface validates are done by ‘AP_CARD_VALIDATE’


Flow chart for different methods available in credit card process:


Both pay method



Company pay method

Individual Pay method


Credit card technical flow:


For more details with an example please read my other blog
by clicking below link

Credit Card process in detail with example 




Pcard Process:

Setup:

1.       Supplier creation:
Navigation: Payables Manager, Supplier




















2.   Create supplier site
3.   Flag site as Procurement Card enabled (so it shows when purchasing team creates PR with PCARD)







4.       Create employee record in HRMS (this is regular nothing special required)

5.       Create credit card code set:

Bank maintains card code to identify suppliers and supplier types for the transactions that your employee incur when using a purchasing card.

Purpose: when importing the information from bank using the card code default account can be derived.

6.       GL Account sets
In the Credit Card GL Account Sets window, enter a GL Account Set Name and Description.

List the GL accounts that are included in the set. In the Description field, enter the account name that credit card holders will see when they use Web Employees to change the account for a transaction, for example, Office Supplies.


e.g.: when employee verifies the transaction using self-service screen he can overwrite account with what is defined in GL account set.

7.       Create credit card program: use this function to defined card issuer
Make sure card type is chosen has Procurement.









8. Profile:



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

























For example, a card holder's default employee expense account is 01-450-5800. The default account template is --5900. This creates a default transaction account of 01-450-5900. If you have enabled the Build Account From Code option, and the account assigned to the card code is 6000, then during the Credit Card Transaction Validation report, Payables assigns 01-450-6000 as the transaction account. During validation, the employee can overwrite any account segment based on the list of values that you define in the Credit Card GL Accounts window

9.       Credit card:
Create credit card information in the system using this window. You can use profile to the credit card so that system defaults are performed





























10.   Transaction adjustment:
When PCARD data is loaded and validated then the validated information will be available in below screen so admin can verify
Or employee will be notified who can verify the transaction or make change to default account or split the transaction before verification.


We will go in details on how PCARD transaction are validated, verified and posted to AP.





































Once setups are done, it’s time to run a test case.

PCARD process overview:

a.       Once bank send the file, pick the file using custom program (no standard program to load pcard credit transaction unlike for credit card transaction US Banks/AMEX program are available) and load data to AP_EXPENSE_FEED_LINES table
b.      'Procurement Card Transactions Validation Program' will validate the loaded transaction.
c.       Once loaded the transaction is available in ‘Procurement card transaction’ form (as described above).
d.      'Procurement Card Transactions Verification Process' program this will verify employee (who owns pcard) and send notification to employee to validate the transaction.
e.      Employee has to login and look for notification and can edit the distribution to correct the account/cost center, split and verify the transaction.
Workflow name: AP Procurement Card Employee Verification Workflow
f.        'Procurement Card Transactions Approval Process' program will send notification to manager for approval.
g.       Based on the profile setup Manager can either approver or can receive FYI notification or do nothing. If Approval is required then Manager has to login and look for notification and can edit the distribution to correct the account/cost center, split and verify the transaction.
Workflow name: AP Procurement Card Manager Approval Transaction
h.      Once manager is verified the transaction status changes to APPROVED.
i.         'Create Procurement Card Issuer Invoice' program will to move APPROVED transaction to ap_invoices_interface table
j.        'Payables Open Interface Import' program will import AP interface transaction.
k.       If AP approval has been setup then approval process is initiated and once fully approved invoice will be ready for payment.

l.         CARD NUMBER and CARD ID are mandatory to populate in interface table.
m.    Interface validates are done by – AP_WEB_PCARD_WORKFLOW_PKG

Process flow:


Purchase card technical flow:


For more details with an example please read my next blog
by clicking below link

PCard process in detail with example 


Difference between credit and purchase card process:

Credit Card
Purchase Card
Iexpense module is used
Use self-service functionality is used
Multiple approvers can be set
Only one level of approval can be set
Not applicable
Transactions can be updated with different natural account and cost center
Categorization: user can categorize transaction itself not at distribution level
Categorization: user can categorize transaction at distribution record
Not applicable
Transactions can be spitted