Procure To Pay (P2P) When Only The

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

Eric Guether
[email protected]
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
Ariba Spend Mgmt.

Master Data Requisition Purchase Receive Invoice

PO to Supplier

Operating Units
OK2Pay
Suppliers & Sites Remittance
(Approved)
Locations Data
Invoices
Chart of Accounts

Oracle EBS R12

Master Data Account Pay

Payment to Supplier
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