Oracle EBS: P2P with EBS Payables and Non-EBS Procurement


Published on

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.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Restrictions on Shipping Details tab: Old MOS Bug 753516. MOS Doc 2499281.1. MOS Doc 308088.1. MOS Doc 1456463.1.
  • Oracle EBS: P2P with EBS Payables and Non-EBS Procurement

    1. 1. Procure To Pay (P2P) When Only The Second 'P' Is Oracle E-Business Suite (EBS) Eric Guether
    2. 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. 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. 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. 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. 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. 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. 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. 9. P2P Solution: Technical Overview
    10. 10. Discussion Areas • Supplier Master Data • Location Master Data • Chart of Accounts (COA) Master Data • Invoice Transaction Transfer • Remittance Data Transfer
    11. 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. 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. 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. 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. 15. Default Bill-To Location
    16. 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. 17. Location Example
    18. 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. 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. 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. 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. 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. 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. 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. 25. Payables Open Interface Forms • AP_INVOICES_INTERFACE • AP_INVOICE_LINES_INTERFACE
    26. 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. 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. 28. Alert Example for Imported Batches
    29. 29. Script for Imported Invoice Batches
    30. 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. 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. 32. Alert Example for Rejected Invoices
    33. 33. Script for Rejected Invoices • Refer to white paper for complete script and assumptions
    34. 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. 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. 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. 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. 38. Example: Oracle Payment
    39. 39. Example: Remittance Data in Ariba
    40. 40. Points to Ponder: Remittance Data • Consider Voided Payments and Partial Payments in Your P2P Integration Design
    41. 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. 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