Skip to main content

 

 

Coupa Success Portal

Oracle to Coupa Integration Points

Suppliers

Most customers maintain Supplier master data in their ERP or some form of Supplier Data Hub. It is a complex object with a variety of child entities, such as Business Classification, Vendor Contacts, Vendor Sites (Purchasing and Pay Sites), Bank Information, OFAC Compliance, etc. While all these are critical for effective Supplier Management, for self-service requisitioning and PO execution, Coupa captures about 15 key attributes of the Supplier records.

The key attributes required for the Supplier object focus on the Vendor Status, Matching level (2-way, 3-way or 4-way), PO Communication method (cXML, Email, etc), Hold Status and a few others, such as Payment Terms, Shipping Terms, etc that are primarily used for defaulting within Coupa. This is by design, to simplify data capture within Coupa and therefore focus on the key attributes that are required for effective self-service procurement and Payables processes through Coupa.

Integration Options

  • Coupa Standard Flat Files
  • Coupa API
  • Oracle Open Interface tables and Oracle API

Supplier Sites (Purchasing & Pay)

Oracle supports the concept of a Supplier Site and both a purchasing and pay site tied to a supplier site. Both the purchasing and pay sites can be tied to specific operating units within Oracle. This functionality, in Oracle, allows customers to have different payment terms, PO transmission methods, etc. for each purchasing site.

Many companies choose to have a one to one mapping in Coupa, between the purchasing and pay sites within Oracle. This ensures simplicity for the integration.

Pay Sites

The pay-to sites (remit-to sites) for a given supplier in Coupa map to the Supplier sites (that are primarily Pay Sites) within Oracle for a given Supplier, and are used in the invoicing process.

While there is a great deal of information that is generally captured on the Pay Sites within Oracle, from a Coupa perspective, we simplify the data that is required so that the AP team has the ability to select the right Pay Site at the time of creating the Invoice. The information that is required for processing the invoice and payment disbursement will continue to exist in Oracle.

The integration provides for Add/Edits to the Remit-to Site. The Remit-to Sites in Coupa are also designed to allow the capture of any custom information added to the basic attributes.

Integration Options

  • Coupa Standard Flat Files
  • Coupa API

Purchasing Sites

Each supplier and purchasing site combination should be modeled as a single supplier record in Coupa. The integration that pulls the data out of Oracle should iterate through the different purchasing sites and create records for each supplier/purchasing site combination. The supplier name in Coupa should be created with this in mind, such that the end user, when searching for a supplier, can enter their OU or a zip code or some other relevant information to distinguish between the supplier/purchasing site combinations.

On the supplier record in Coupa we have a field Number where we would store the Oracle vendor identifier concatenated with the Oracle purchasing site identifier. That information would then be split into two different fields on the PO and Invoice files that go back into Oracle. For reference, look at the following screenshot.

Oracle ID

The user experience is enhanced with this approach, as the relevant information is readily available to them at the time of searching for the supplier. For reference, look at the following screenshot.

Supplier

Any catalog items or web forms will have to be tied to each supplier/purchasing site combination in Coupa. Typically suppliers that have multiple purchasing sites have limited catalog information and are suppliers that provide services. A supplier that supports catalog items or punchouts, will have central purchasing sites across the supplier, therefore in Coupa they will have a single record.

Users/Employees (from Oracle HR)

In general, the source of data for the User record in Coupa is derived from a variety of sources within Oracle, primarily the FND tables (for User login information, Responsibilities, Security, etc.) and HR tables (depending on your shared or full install of HR). This is primarily used to capture the user assignments, their current valid assignment status, and their possible band level that will be used for assigning appropriate approval limits (employee/supervisor hierarchy, etc.).

Given the scope of the user activity within Coupa, we have a simplified model for User management within Coupa. The following considerations could have a dramatic impact on your integration efforts for the User object:

  • Approval Limits: to ensure that your users accurately reflect the approval limits in comparison to Oracle.
  • Large organizational changes: while not common, these should be considered for your integration design and possibly scope-in or out based on cost/benefit analysis.
  • Content Security: in Coupa you can control access to the catalog content, and based on your business requirements, segregate the catalog content across different business groups or operating units.
  • GL Account Code access and security: if the usage of your account codes is designed in a way to provide necessary controls around the ability of different users to charge to different accounts, there is potential for designing the billing account security into the User integration.
  • If you implement SAML or other external Authentication mechanisms, then it will also be required to address the necessary Key attributes on the User record to facilitate seamless single sign-on.
  • Should you standardize on a specific Coupa role to assign to all new employees, when your users move from one Business Unit to another within in Oracle, you'll generally need to consider the potential role changes and content security along with that change.

Integration Options

  • Coupa Standard Flat Files
  • Coupa API

Accounting Data

In Coupa you have the following options for accounting:

Static Accounting model: We've taken the approach of capturing the valid Code Combinations as Account strings. This model, while it helps keep the GL Account management simple in Coupa, does have the possibility of significantly increasing the number of possible accounts (even into millions) based on all possible valid code combinations

Dynamic Accounting model: This model allows for capturing just the segment values, code combination validation rules, dynamic inserts, etc.

Integration Options

  • Coupa Standard Flat Files
  • Coupa API
  • Oracle Open Interface tables and Oracle API

Projects and Tasks

There are a couple of design considerations for Integrating Oracle Projects and Coupa. In general, from a procurement perspective, the requirement is to accurately reflect the committed costs. This is addressed by capturing the Project and Task information on the Requisition and Purchase Orders and interfacing that information to Oracle Projects.

As part of the Coupa design, we'll expose the Project and Task fields for the end users to select the appropriate values. Once the Requisitions are approved and PO are created, we'll cascade the Project/Task information from Requisition to PO and then, when we interface the PO to Oracle, we'll transfer the Project and Task information either in the flat files or in the relevant fields in the Oracle PO Open Interface tables. Since any receipts created for the PO in Coupa will carry forward the Project/Task information, we will also transfer the Project/Task information while interfacing the receipts from Coupa to Oracle.

Another design consideration is to model the Projects and Tasks into your COA Structure.

In Coupa, the focus will be in allowing the end users to capture the required Project/Task information and interfacing that to Oracle. Within Oracle, there are call-outs from Oracle Purchasing to Projects to keep the data synchronized.

  • The Projects and Tasks will be modeled using the Lookup objects in Coupa. You may choose to feed just the valid Project/Task combinations to Coupa and maintain it as one lookup or mimic the relationship in Oracle and model them as different objects within Coupa.
  • Similar to how the Projects and Tasks are referenced on the Requisition and PO object within Oracle, Coupa will take the same approach and let the detailed information about the Projects and Tasks continue to exist in Oracle.

Integration Options

  • Coupa Standard Flat Files
  • Coupa API

Invoice Payments

Once the invoices are paid in Oracle, customers see the following benefits of integrating the payment information from Oracle to Coupa:

  • Your Payables team and other business users (that have access to Invoices) can easily see the payment information on the invoices. This will help with a quick turnaround on all inquiries from the suppliers.
  • Suppliers can also get this information through the CSN for their invoices, avoiding the need for making calls into your Payables team or business users, making your suppliers and your company more productive.

Integration Options

  • Coupa Standard Flat Files
  • Coupa API
  • Oracle Open Interface tables and Oracle API
  • Was this article helpful?