Procure To Pay (P2P) When Only The
Second 'P' Is Oracle E-Business Suite (EBS)
Eric Guether
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
