Oracle EBS ERP user group presentation. Originally presented in April 2013 at the COLLABORATE 13 conference in Denver. Addresses issues with P2P when only the second 'P' is in Oracle EBS. Specifically, integrating Oracle R12 Payables with an Ariba Spend Mgmt. procurement system.

1. Procure To Pay (P2P) When Only The
Second 'P' Is Oracle E-Business Suite (EBS)
Eric Guether
eguether@gmail.com

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. P2P Solution: Functional Overview
Requisition Purchase Receive InvoiceMaster Data
Account PayMaster Data
Ariba Spend Mgmt.
Oracle EBS R12
Operating Units
Suppliers & Sites
Locations
Chart of Accounts
PO to Supplier
Payment to Supplier
OK2Pay
(Approved)
Invoices
Remittance
Data

9. P2P Solution: Technical Overview

10. Discussion Areas
• Supplier Master Data
• Location Master Data
• Chart of Accounts (COA) Master Data
• Invoice Transaction Transfer
• Remittance Data Transfer

11. 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

12. 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

13. 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?

14. 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

15. Default Bill-To Location

16. 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

17. Location Example

18. 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

19. 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)

20. 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?

21. 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

22. 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

23. 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

24. 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

25. Payables Open Interface Forms
• AP_INVOICES_INTERFACE
• AP_INVOICE_LINES_INTERFACE

26. 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

27. 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

28. Alert Example for Imported Batches

29. Script for Imported Invoice Batches

30. 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?

31. 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

32. Alert Example for Rejected Invoices

33. Script for Rejected Invoices
• Refer to white paper for complete script and
assumptions

34. 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

35. 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:

36. 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

37. 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

38. Example: Oracle Payment

39. Example: Remittance Data in Ariba

40. Points to Ponder: Remittance Data
• Consider Voided Payments and Partial Payments
in Your P2P Integration Design

41. 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

42. 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