Procure To Pay (P2P) When Only The

Second 'P' Is Oracle E-Business Suite (EBS)

Eric Guether

eguether@gmail.com

Introduction

• About the Speaker– Worked with EBS [11i & R12 ] since 2001 as

business systems manager and functional analyst

– Presented at five previous OAUG COLLABORATE and predecessor conferences from 2004 to 2008

Objectives

• Identify Points to Consider When Integrating Oracle Payables with an External Procurement System– First ‘P’ in P2P is an external system

– Second ‘P’ in P2P is existing Oracle EBS Payables

• Discuss Invoice Import Issues

• Show Examples of Business Activity Monitoring

In Scope

• E-Business Suite R12 Payables– Also relevant for EBS 11i Payables

• Corporate Purchases– Services and Non-Inventory Goods

• Key Interfaces– Master Data– AP Invoices– Remittance Data

Out of Scope

• Oracle Application Integration Architecture (AIA)

– Topics still relevant when AIA or BPEL are used

• Employee Master Data & Approval Hierarchies

• Inventory Purchasing– PO receipts into Oracle Inventory

Business Case: Before P2P

• Corporate Org Had No Purchasing System– Centralized oversight of corp. spend was reactive

– Exceptions often detected post-purchase

• Invoices Entered Directly into Oracle Payables– No automated controls from 2-way / 3-way matching

– Authorization for payment signature on paper invoice

Business Case: Solution

• Implement a Procurement Process and System– New System: Ariba Spend Management

– Punchout catalog buying and electronic invoicing enabled through Ariba Supplier Network (ASN)

– Oracle Purchasing / iProcurement considered but not selected

• Integrate New System with Existing Oracle Payables for P2P

P2P Solution: Functional Overview

Requisition Purchase Receive InvoiceMaster Data

Account PayMaster Data

Ariba Spend Mgmt.

Oracle EBS R12

Operating UnitsSuppliers & Sites

LocationsChart of Accounts

PO to Supplier

Payment to Supplier

OK2Pay(Approved)

Invoices

RemittanceData

P2P Solution: Technical Overview

Discussion Areas

• Supplier Master Data

• Location Master Data

• Chart of Accounts (COA) Master Data

• Invoice Transaction Transfer

• Remittance Data Transfer

Supplier Master Data

• Existing Oracle Payables Supplier Master is Data Source for New Procurement System– New suppliers / sites added to Oracle, then

interfaced to external procurement system

– Changes to suppliers / sites made in Oracle, then interfaced to external procurement system

• Advantages– Master data already in Oracle

– Leverage existing process to maintain

Issue: Purchasing Sites

• Our Oracle Supplier Master Had No Purchasing Sites– Had only needed Pay, or remit-to, sites before P2P

• Solution– For implementation: Add Purchasing sites to Oracle

for suppliers Big Effort

– Post-implementation: Enhance the supplier creation process to include capture & entry of Purchasing sites for Ariba POs

Points to Ponder: Suppliers

• Consider Impact of Disabling a Supplier or Site When Designing Your P2P Integration

• How Will the Disabling or End-Dating of a Supplier or Site in Oracle Affect:– Ability to enter new requisitions, POs, or invoices in

the external procurement system?

– Any existing transactions in the procurement system?

– Ability to retrieve historical transactions in the procurement system?

Location Master Data

• Existing Oracle Locations Master is Data Source for New Procurement System

• One Bill-To Address for an Operating Unit (OU) Based on the OU’s Default Financial Options

• Each OU Can Have Multiple Ship-To Locations

• Advantages– Some master data already existed in Oracle

– Leverage existing process to maintain

Default Bill-To Location

Issues: Ship-To Addresses

• How to Identify & Control Ship-To Locations?

– Many Ship-To Locations Were Not in Oracle

– EBS Locations form restricts changes on Shipping Details tab if Inventory or Purchasing not installed

– Solution: Maintain a custom mapping table for valid ship-to locations for each OU

Location Example

Issue: Locations vs. Sites

• Original Integration Used Oracle’s Location ID & Supplier Site ID as Unique Identifiers– Procurement system stores locations & supplier sites

in same Addresses table with different usage types

– ID values not unique between Oracle supplier site IDs and Oracle location IDs!

• Solution– Modify Locations interface to append a prefix

– Example: Location ID 12345 sent to Ariba as LOC12345

Chart of Accounts Master

• Oracle Chart of Accounts (COA) Code Combs & Segment Values Sent to Procurement System– Exclude parent account-level natural account

values– Exclude end-dated or disabled COA combinations

and segment value

• Advantages– COA already existed in Oracle

– Leverage existing process to maintain

– Intercompany segment facilitates allocations across multiple companies (balancing segments)

Points to Ponder: Chart of Accts

• Identify Restrictions on Account Segment Values or Combinations for Purchases

• Consider Impact of Disabling an Account Segment Value or Combination– Will open procurement system transactions have

errors if coded with segment values or combinations subsequently disabled in Oracle?

– How frequently will OK2Pay invoices be rejected by Oracle EBS upon import if they include an account code combination recently disabled in Oracle?

Invoice Transactions

• Entered & Approved in Procurement System– Most invoices just need to be acknowledged by the

requisitioner [no receiving transaction]

– Certain purchases require a receiving transaction [expense-type of PO; no inventory receipt]

• Accounted & Paid in Oracle Payables– OK2Pay: Transfer of approved invoices to Oracle

– Imported via Oracle’s seeded invoice interface tables & program

Four-Step Process

• Step 1: Pull OK2Pay Invoice File from Ariba– Custom Oracle concurrent program

• Step 2: Load OK2Pay Invoices onto Staging– Custom Oracle concurrent program & staging tables

• Step 3: Load from Staging to Interface & Run AP Import(s)– Controlled by custom concurrent program– Custom program errors if system date does not fall in

open AP period– Loads seeded Oracle Payables Open Interface tables

Four-Step Process (continued)

• Step 3 (continued)– Invoices grouped by AP operating unit (OU)

[org ID]– Spawns one seeded AP Import request per OU

[“Payables Open Interface Import” program]– Batch names include system date and group ID to

ensure uniqueness– Errors if system date does not fall in open AP period

• Step 4: Place Special Holds– Custom Oracle concurrent program– Future: Also validate imported batches

Payables Open Interface Tables

• AP_INVOICES_INTERFACE– Where OK2Pay invoice headers are loaded

• AP_INVOICE_LINES_INTERFACE– Where OK2Pay invoice lines are loaded

– Includes account code combinations

• AP_INTERFACE_REJECTIONS– Holds rejection reason for invoices on the interface

table that was rejected by Oracle upon import

Payables Open Interface Forms

• AP_INVOICES_INTERFACE

• AP_INVOICE_LINES_INTERFACE

Rejection Reasons Encountered• DUPLICATE INVOICE NUMBER

• NO TERMS INFO

• INVALID PAY METHOD

– If null, import pulls in the default pay method from the invoice’s supplier site

• INVALID SUPPLIER SITE

• INVALID DISTRIBUTION ACCT [line level]

• NO INVOICE LINES [line level]

• INVALID LINE TYPE LOOKUP [line level]

• INCONSISTENT OPERATING UNITS

Invoice Importing Tips

• Create a Unique Invoice Source

• Consider Loading First into Custom Staging Tables

• Prepare E-mail Alerts or Reports to Summarize Imported Invoice Batches

• Design an Error Handling Process for Rejected Invoices

Alert Example for Imported Batches

Script for Imported Invoice Batches

Error Handling Considerations

• Who Decides How to Handle Rejected Invoices?

• Who Corrects through the Oracle Invoice Interface Form?

• What Errors Should Be Corrected:– Only on the Oracle interface table?

– In both the procurement system and on the interface table?

• How Will Everyone Be Notified of Rejects?

Monitoring Rejected Invoices

• Leveraged Oracle Alert for Daily E-mail Notifications– SQL script for alert provided in white paper– Lists all current rejects whether new or also in

previous business day’s alert e-mail

• Something’s Better Than Nothing– Any notification tool [e-mail alert, event, report,

Discoverer query] is better than reviewing Payables Open Interface Import Reports for rejects

Alert Example for Rejected Invoices

Script for Rejected Invoices

• Refer to white paper for complete script and assumptions

Points to Ponder: PO Number

• Consider Storing PO # from External System in DFF of Imported Invoice for Reference– Cannot import external system’s PO # into the

PO_NUMBER column of the invoice interface

Points to Ponder: Period-End

• Rejected Invoice Records at End of AP Period Need to be “Manually Swept” to Next Period

– GL_DATE on AP_INVOICES_INTERFACE table:

– ACCOUNTING_DATE on AP_INVOICE_LINES_ INTERFACE table:

Points to Ponder: Tax Rates

• Importing Invoices with EBTax Tax Rates Can Be Quite Confusing

– MOS doc 840262.1 is a must-read white paper: Use Cases for Importing Tax Lines Through the Payables Import Process

– Workaround: Compute taxes in procurement system; import tax amounts on lines with line type of ITEM and distributions for tax accounting but no EBTax tax rate

Remittance Data

• Transfer of payment data from Oracle to external procurement system for informational purposes– Oracle payment number [check number]

– Payment method

– Payment amount & currency

– Payment process request (PPR) name

– Payment status

Example: Oracle Payment

Example: Remittance Data in Ariba

Points to Ponder: Remittance Data

• Consider Voided Payments and Partial Payments in Your P2P Integration Design

Overall P2P Considerations

• What Resources Will Be Needed to Maintain Your Interfaces?

• How Will Future Upgrade Considerations Affect Your Integration?

• Consider the Future Shutdown or Disabling of an Operating Unit (OU) in Your Integration Design

Conclusion

• P2P is Possible Where Only the 2nd ‘P’ is in EBS– Integration of existing Oracle EBS system with a

new procurement system can be successful

• Thorough Design Analysis Required