P2P Technical Flow Fusion

Introduction

The P2P technical flow in Oracle Fusion (Procure-to-Pay flow) is one of the most critical integration-driven business processes in enterprise implementations. It connects procurement, supplier management, receiving, invoicing, and payments into a seamless lifecycle. In modern Oracle Fusion Cloud (Release 26A), this process is heavily dependent on integrations, APIs, ESS jobs, and data orchestration using tools like Oracle Integration Cloud (OIC Gen 3), BIP reports, and FBDI/REST services.

From a consultant’s perspective, understanding the technical flow of P2P is what differentiates a functional consultant from a strong techno-functional or integration expert. In real implementations, 70% of issues in P2P are not functional—they are technical (data not flowing, integration failures, mapping issues).

In this blog, we will break down the P2P technical flow step by step with real-world implementation insights.

What is P2P Technical Flow in Oracle Fusion?

The P2P technical flow in Oracle Fusion refers to how data moves between different modules and systems during the procurement lifecycle, using:

• Tables and database objects
• ESS (Enterprise Scheduler Service) jobs
• Web services (REST/SOAP)
• Integration tools (OIC Gen 3)
• Interface tables (FBDI)
• Reporting tools (BIP, OTBI)

At a high level, the P2P process includes:

1. Requisition Creation
2. Purchase Order Creation
3. Goods Receipt
4. Invoice Creation
5. Payment Processing

Each step has a backend technical layer that ensures data consistency across modules like Procurement, Receiving, Payables, and Cash Management.

Real-World Integration Use Cases

1. External Procurement System Integration

In large organizations, requisitions may originate from third-party systems like SAP Ariba or custom portals.

Flow:

• External system → OIC Gen 3 → Fusion REST API → Requisition created

2. Supplier Invoice Automation

Invoices are often scanned and processed via OCR tools.

Flow:

• OCR tool → OIC → Payables Invoice Interface → ESS Job → Invoice Import

3. Payment File Integration with Bank

Payments generated in Fusion are sent to banks via secure integrations.

Flow:

• Payment Process → BIP XML → OIC → Bank SFTP

Architecture / Technical Flow

Below is the simplified technical architecture of the P2P flow:

1. Requisition Stage

• UI Entry OR External Integration
• Tables: POR_REQUISITION_HEADERS_ALL
• APIs: Requisition REST API
• ESS Jobs: None (Real-time processing)

2. Purchase Order Creation

• Auto-create from requisition OR manual creation
• Tables: PO_HEADERS_ALL, PO_LINES_ALL
• ESS Job: “Create Purchase Orders”

3. Receiving Process

• Receipt creation via UI or mobile
• Tables: RCV_SHIPMENT_HEADERS, RCV_TRANSACTIONS
• Impact: Inventory and accrual accounting

4. Invoice Processing

• Invoice Entry OR Import
• Tables: AP_INVOICES_ALL, AP_INVOICE_LINES_ALL
• ESS Job: “Import Payables Invoices”

5. Payment Processing

• Payment batch creation
• Tables: AP_CHECKS_ALL
• ESS Jobs:
  • “Create Payment Process Request”
  • “Format Payment Files”

Prerequisites

Before working on P2P technical flow, ensure:

• Business Units and Ledgers are configured
• Suppliers and Supplier Sites are created
• Procurement Business Function is enabled
• Chart of Accounts is defined
• Bank Accounts are configured
• OIC Gen 3 instance is available (for integrations)
• Required roles:
  • Procurement Agent
  • Accounts Payable Manager
  • Integration Specialist

Step-by-Step Build Process

Step 1 – Requisition Integration Setup

Navigation:
Navigator → Tools → REST API → Requisition

Technical Approach:

• Use REST API: /fscmRestApi/resources/latest/requisitions

Sample Payload:

Step 2 – Purchase Order Automation

Navigation:
Navigator → Procurement → Purchase Orders

Technical Logic:

• Use AutoCreate functionality
• ESS Job: Create Purchase Orders

Key Tables:

• PO_HEADERS_ALL
• PO_DISTRIBUTIONS_ALL

Step 3 – Receiving Integration

Navigation:
Navigator → Receiving → Receipts

Technical Options:

• REST API for receipts
• FBDI upload for bulk receiving

Interface Table:

• RCV_HEADERS_INTERFACE

Step 4 – Invoice Import Process

Navigation:
Navigator → Payables → Invoices → Import

Technical Setup:

1. Load data into interface tables:
   • AP_INVOICES_INTERFACE
   • AP_INVOICE_LINES_INTERFACE
2. Run ESS Job:
   • Import Payables Invoices

Step 5 – Payment Processing Integration

Navigation:
Navigator → Payables → Payments

Technical Flow:

1. Create Payment Process Request
2. Generate Payment File (XML)
3. Use BIP Template
4. Send via OIC to Bank

Testing the Technical Component

Example Scenario

Use Case: End-to-end P2P transaction

1. Create requisition via REST API
2. Convert to Purchase Order
3. Create receipt
4. Import invoice
5. Process payment

Expected Results

• Requisition created successfully
• PO generated with correct supplier
• Receipt recorded in system
• Invoice matched with PO
• Payment file generated

Validation Checks

• Check tables for data consistency
• Verify ESS job logs
• Validate accounting entries
• Confirm payment file format

Common Errors and Troubleshooting

Best Practices

1. Use OIC Gen 3 for All Integrations

Avoid direct point-to-point integrations. Always use OIC for scalability.

2. Validate Data at Source

Most P2P failures occur due to bad data.

3. Monitor ESS Jobs Regularly

Use:
Navigator → Tools → Scheduled Processes

4. Use Standard APIs

Avoid custom PL/SQL unless absolutely required.

5. Maintain Error Logging in Integrations

Always capture error payloads in OIC.

Frequently Asked Questions (FAQs)

1. What is the main technical component in P2P flow?

The main components are REST APIs, interface tables, ESS jobs, and OIC integrations.

2. Can we automate the entire P2P process?

Yes, using OIC Gen 3 and APIs, the entire flow can be automated from requisition to payment.

3. What is the role of ESS jobs in P2P?

ESS jobs handle background processing like:

• PO creation
• Invoice import
• Payment processing

Summary

The P2P technical flow in Oracle Fusion is not just about procurement—it is about data orchestration across multiple systems and modules. As an Oracle consultant, mastering this flow means understanding:

• How data moves across modules
• Which tables and APIs are involved
• How integrations are built using OIC Gen 3
• How to troubleshoot real-time issues

In real projects, the difference between a junior and senior consultant lies in how well they understand these backend flows.

If you want to go deeper, refer to Oracle’s official documentation:

https://docs.oracle.com/en/cloud/saas/index.html