Oracle Fusion

The Graphite adapter for Oracle Fusion Cloud ERP synchronizes supplier master data from graphiteConnect into your Oracle Fusion environment. The integration is fully cloud-to-cloud: it runs entirely within the Graphite platform and communicates with your environment through Oracle's standard REST APIs. There is no software to install, host, or maintain on your side.

When suppliers create or update their information in graphiteConnect, the adapter automatically creates or updates the corresponding records in Oracle Fusion — the supplier profile, addresses, contacts, sites, attachments, tax information, and banking details, including banks, bank branches, external bank accounts, and payment instrument assignments.

How the Adapter Works

The adapter maintains Oracle supplier data the same way an integration built by your own team would: it authenticates against your environment, reads Oracle to determine what already exists, and then creates or updates records through Oracle's standard REST resources. It never accesses the Oracle database directly, so all of Oracle's built-in validations, business rules, and security checks apply to every change.

Architecture at a Glance

Nothing to install: The adapter is hosted and operated by Graphite. Your setup consists of creating an integration user (or OAuth client) and sharing connection details. See Setup.
Two authentication options: HTTP Basic authentication with a dedicated integration user, or OAuth 2.0 through your Oracle Identity Domain. Credentials are stored encrypted in Graphite's secrets management. See Setup.
Standard REST resources: All reads and writes go through Oracle Fusion's published REST APIs (suppliers, externalBankAccounts, cashBanks, and so on). Oracle's validations, duplicate checks, and approval rules apply to every record.
Encrypted in transit: All communication uses HTTPS (TLS 1.2+).
Existence checks before writes: Every record type is looked up in Oracle first — the adapter reuses and updates existing records rather than creating duplicates, and stores the resolved Oracle IDs in Graphite for future runs.

flowchart LR
    subgraph GC["Graphite Cloud"]
        API["Graphite Public API"]
        ADP["Oracle Fusion Adapter"]
        API --- ADP
    end
    subgraph OC["Oracle Cloud"]
        IDM["Oracle Identity Domain<br>(OAuth option)"]
        REST["Oracle Fusion REST APIs"]
    end
    ADP -. "OAuth token (optional)" .-> IDM
    ADP -- "HTTPS + Basic or Bearer auth" --> REST

Data Flow

Each synchronization run processes the suppliers whose data has changed since the last sync:

flowchart TD
    A["Supplier data changes in Graphite"] --> B["Adapter picks up changed supplier"]
    B --> C{"Supplier already known<br>in Oracle?"}
    C -- No --> D["Match by supplier number, tax IDs,<br>or name to prevent duplicates"]
    D -- "No match" --> E["Create supplier,<br>capture Oracle IDs"]
    D -- "Match found" --> F["Update existing supplier"]
    C -- Yes --> F
    E --> G["Sync profile data: addresses, contacts,<br>attachments, classifications, tax data"]
    F --> G
    G --> H["For each site: site, assignments,<br>payee, payment methods"]
    H --> I["For each bank: resolve bank, branch,<br>external account, instrument assignment"]
    I --> J["Acknowledge Oracle IDs<br>back to Graphite"]

Key behaviors:

Create vs. update: If Graphite already holds the Oracle Supplier ID from a previous sync, the adapter updates that supplier. Otherwise it runs duplicate-prevention matching before creating anything. See Supplier Matching & Duplicate Prevention.
Sites follow spend authorization: Supplier sites (and their payees, payment methods, and bank accounts) are only synchronized for suppliers with a Spend Authorized business relationship. The adapter can optionally submit the spend authorization request itself to promote a prospective supplier. See Setup.
Acknowledgements: After each supplier is processed, the adapter writes the resulting Oracle identifiers back to the supplier's Graphite profile — the Supplier ID and supplier number, address IDs, site IDs, external bank account IDs, bank and branch party IDs, and payment instrument assignment IDs. These stored IDs make future syncs target the same Oracle records. See ERP Record.

Setup

Prerequisites

Admin access to your Oracle Fusion environment (Security Console and, for the OAuth option, your Oracle Identity Domain).
Your environment's REST API base URL, including the API version, for example:
https://<servername>.fa.<region>.oraclecloud.com/fscmRestApi/resources/11.13.18.05
If your organization restricts API access by source IP, plan to allowlist Graphite's egress IP addresses (available from your Graphite integration contact).

Step 1 — Create a dedicated integration user

All changes the adapter makes run under a dedicated Oracle user you create and control, so every change is attributable and scoped to the access you assign.

In Oracle Fusion, create a user for the integration (for example GRAPHITE_INTEGRATION) via the Security Console.
Assign roles that grant the following capabilities:
- Supplier profile management — create and update suppliers, supplier addresses, contacts, sites, site assignments, attachments, business classifications, and products & services
- Supplier qualifications — create supplier qualification question responses (if used)
- Tax setup — create and update party tax profiles, tax registrations, and party fiscal classifications (if used)
- Cash management — read, create, and update banks and bank branches
- Payables / payments — create and update external payees, external bank accounts, and payment instrument assignments
- Spend authorization — submit spend authorization requests (only if using automatic promotion)

Note: Oracle role names vary between environments and versions, so we recommend starting from your organization's standard supplier-administration and cash-management roles, validating the integration in a test pod, and then tightening to least privilege.

Step 2 — Set up authentication

The adapter supports two authentication methods. Most customers use Basic authentication; OAuth 2.0 is available where required by your security policies.

Option A — Basic authentication

Set a strong password for the integration user from Step 1.
Provide the credentials to your Graphite integration contact through a secure channel.

Graphite stores the username and password encrypted in its secrets-management system; they are decrypted only at the moment a sync run authenticates.

Option B — OAuth 2.0

With OAuth, the adapter authenticates with bearer tokens issued by your Oracle Identity Domain instead of a password. Graphite obtains tokens via the authorization-code flow and keeps them current automatically using refresh tokens.

In the Oracle Identity Domain (IDCS) that fronts your Fusion environment, create a confidential application for Graphite:
- Allowed grant types: Authorization Code and Refresh Token
- Redirect URI: the Graphite callback URL (provided by your Graphite integration contact)
- Scope: the resource scope that grants access to your Fusion REST APIs
Provide the client ID, client secret, identity domain URL, and scope(s) to your Graphite integration contact.
A one-time authorization is then completed in the Graphite application: sign in as the integration user when prompted by Oracle. Because tokens issued by the authorization-code flow act on behalf of the authorizing user, this ensures all API calls execute with the integration user's permissions.

Note: The authorization can be revoked at any time — from Graphite, or by deactivating the OAuth client or the integration user in Oracle.

Step 3 — Provide the configuration values to Graphite

Value	Description	Example
REST base URL	Your environment's REST root, including API version	`https://<servername>.fa.<region>.oraclecloud.com/fscmRestApi/resources/11.13.18.05`
Authentication type	`basic` or `oauth`	`basic`
Username / password	Integration user credentials (Basic auth)	—
Client ID / secret, identity domain URL, scopes	OAuth client details (OAuth only)	—

The Graphite team then configures the integration — including the field mapping between your Graphite profile and Oracle — and validates it with you, typically first against a test pod.

Spend authorization auto-approval

If your integration uses automatic promotion of prospective suppliers, the adapter submits a spend authorization request on the supplier and waits up to five minutes for it to be approved. For this to work, your Oracle approval rules must auto-approve spend authorization requests submitted by the integration user. If the request is not approved within the window, the run reports an error and site-level data is not synchronized until the supplier is spend authorized.

Data Scope

The adapter maintains Oracle supplier master data. It can synchronize:

Supplier profile — names, business relationship, tax identifiers, and other supplier attributes per your mapping
Addresses — supplier addresses, with duplicate detection by address name and address fields
Contacts — supplier contacts (matched by email) and their contact addresses
Attachments — files from the supplier's Graphite profile attached at the supplier and site level
Business classifications — diversity classifications from supplier certificates
Products and services — supplier product/service category assignments
Qualification question responses — answers pushed into Oracle Supplier Qualification (create-only; Oracle does not allow updates through this API)
Tax data — party tax profiles, tax registrations, and third-party fiscal classifications
Sites — supplier sites per procurement BU, site assignments, and site attachments (for Spend Authorized suppliers)
Banking — banks, bank branches, external bank accounts, external payees, payment methods, and payment instrument assignments
Spend authorization — optional automatic promotion of prospective suppliers

Exactly which fields are synchronized is controlled by a per-customer mapping configured with the Graphite team. Descriptive flexfields (DFFs) are supported on any resource — mapped DFF attributes are passed through on the standard payloads. See Transformations.

Oracle API Reference

All calls target Oracle Fusion's standard REST resources under your environment's REST root.

Resource	Operations	Purpose
`suppliers`	GET, POST, PATCH	Look up, create, and update suppliers
`suppliers/{id}/action/submitSpendAuthorizationRequest`	POST	Submit a spend authorization request (optional promotion)
`suppliers/{id}/child/addresses`	GET, POST, PATCH	Supplier addresses
`suppliers/{id}/child/contacts`	GET, POST, PATCH	Supplier contacts
`suppliers/{id}/child/contacts/{id}/child/addresses`	GET, POST	Contact address assignments
`suppliers/{id}/child/sites`	GET, POST, PATCH	Supplier sites
`suppliers/{id}/child/sites/{id}/child/assignments`	GET, POST	Site assignments to client BUs
`suppliers/{id}/child/attachments` (supplier and site level)	GET, POST, PATCH	Document attachments
`suppliers/{id}/child/businessClassifications`	GET, POST, PATCH	Diversity / business classifications
`suppliers/{id}/child/productsAndServices`	GET, POST, DELETE	Product and service category assignments
`supplierQualificationQuestionResponses`	GET, POST	Qualification question responses (create-only)
`partyTaxProfiles`	GET, POST, PATCH	Party tax profiles
`partyTaxProfiles/{id}/child/taxRegistrations`	GET, POST, PATCH	Tax registrations
`thirdPartyFiscalClassifications`	GET, POST, PATCH	Party fiscal classifications
`paymentsExternalPayees`	GET, POST, PATCH	External payees
`paymentsExternalPayees/{id}/child/externalPartyPaymentMethods`	GET, POST, PATCH	Payment methods on the payee
`externalBankAccounts`	GET, POST, PATCH	External (supplier) bank accounts
`externalBankAccounts/{id}/child/accountOwners`	GET, POST	Bank account ownership
`instrumentAssignments`	GET, POST, PATCH	Payment instrument assignments
`cashBanks`	GET, POST, PATCH	Banks (Cash Management)
`cashBankBranches`	GET, POST, PATCH	Bank branches (Cash Management)

Supplier Matching & Duplicate Prevention

Before creating a supplier, the adapter works through a matching sequence designed to reuse existing Oracle records and never create ambiguous duplicates:

Known Supplier ID. If Graphite already holds the Oracle Supplier ID from a previous sync, the adapter updates that supplier directly. If the stored ID no longer resolves (for example, the record was purged in a test environment), the adapter falls back to matching instead of failing.
Configured supplier number. If the integration is configured to match on your supplier number, the adapter looks up that exact number and reports an error if it does not exist — it will not create a new supplier in this mode.
Duplicate-prevention matching. Otherwise the adapter searches, in order: supplier number, taxpayer ID (with tax organization type and tax registration number where available), tax registration number, and finally supplier name.

Outcome rules:

Single match — the existing supplier is updated.
No match — a new supplier is created, and the Oracle-assigned Supplier ID and supplier number are written back to Graphite.
Multiple potential matches — the adapter stops and reports an error rather than guessing. An administrator resolves the match once, and subsequent runs use the stored ID.

Supplier creation is additionally protected by locking, so concurrent runs cannot create the same supplier twice.

Bank, Branch & External Bank Account Resolution

Banking is the most sensitive part of supplier synchronization. For each bank account on a site, the adapter resolves records in this order:

Bank (Cash Management)
Bank branch
External bank account
Payment instrument assignment

At each step it decides whether to reuse, update, or create records based on stored IDs and lookup results.

Bank lookup priority

If a bank party ID is already stored from a previous sync, the adapter reads that exact bank.
If the branch is resolved first and identifies its bank, that bank is used.
Otherwise the adapter searches by country + bank number.
If the bank number search does not resolve a match, it falls back to country + bank name.

Candidate handling:

Prefer records that were not created by Graphite (reuse your existing master data first).
Optionally constrain matching to a required character script for the bank name (for example Katakana in Japanese environments).
Prefer an exact bank-name match.
When the search was identifier-based (bank number or party number), the adapter may auto-select the best remaining candidate.
When the search was name-based and multiple candidates remain, the adapter does not auto-pick — it reports the potential matches for administrator review.

Branch lookup priority

If a branch party ID is already stored, the adapter reads that exact branch.
If the mapping explicitly requests a new branch, lookup is skipped and a branch is created.
Otherwise the adapter searches by identifier — branch number first, then SWIFT/BIC by default. The order is configurable, and routing can be driven per site: domestic payment sites match on branch number while international sites match on SWIFT/BIC.

Candidate handling mirrors the bank rules: optional custom filters, preference for non-Graphite-created records, refinement by exact branch and bank name, auto-selection only for identifier-based searches, and no auto-pick on ambiguous name-only matches.

Create vs. update rules for banks and branches

If no bank is found and there are no potential matches, a new bank is created (and a new branch under it).
If potential bank matches exist but no single clear match, the adapter stops and reports an error instead of creating a possible duplicate. (Creation despite potential matches can be enabled per customer where appropriate.)
If the bank exists but the branch does not, a new branch is created under the resolved bank.
If both exist, both IDs are reused.
By default, existing bank and branch master data is not modified — the adapter only reuses the IDs. Updating existing bank/branch records with Graphite data is available as a per-customer option.

External bank account rules

Lookup:

If the external bank account ID is already stored, that account is read directly.
Otherwise the adapter uses Oracle's external-bank-account search with the payment intent, bank and branch identifiers, the masked account number (only the last digits, four by default, are exposed in the search), country/currency, and IBAN when available.
If an IBAN-based search returns no match, it retries without the IBAN.
If multiple accounts are returned, an active account (no end date, or a future end date) is preferred.

Create / update:

If an account is found, it is updated in place.
If no account is found, a new one is created with the supplier as account owner.
If the found account's bank or branch does not match the resolved bank/branch, the adapter does not repoint the account — it reports an error for review.
If the account is owned by a different supplier: when shared accounts are allowed for your integration, the current supplier is added as an additional account owner; otherwise the adapter reports an error and does not use the account.

Payment instrument assignments

The resolved external bank account is assigned to the site's external payee as a payment instrument.
Oracle does not allow changing the instrument on an existing assignment, so when a supplier's account changes the adapter creates a replacement assignment and end-dates the old one.
Optionally, the adapter can end-date all other active assignments for the payee, so the account provided through Graphite is the only active payment instrument.
Payment methods on the payee are created and promoted to primary as mapped.

ID persistence

After successful processing, Graphite stores the external bank account ID (Bank_ERP_Key), bank party ID, branch party ID, and payment instrument assignment IDs on the supplier's profile. Later runs use these stored IDs to target the same Oracle records, minimizing lookups and preventing duplicates.

Error Handling

Per-record errors: Errors are captured per supplier with the Oracle response message, so one supplier's failure never blocks the rest of the run.
No silent guesses: Wherever a lookup is ambiguous — suppliers, banks, branches, bank accounts — the adapter reports an error for review instead of creating or repointing records on a guess.
Targeted retries: Known transient conditions are retried automatically, including attachment revision conflicts and stale stored IDs (the adapter re-matches instead of failing when a stored Oracle ID no longer resolves).
Visibility: All sync results and errors are visible in graphiteConnect's Interfaces Administration tool, and failed suppliers are retried on subsequent runs once the underlying issue is resolved.

Common Technical Questions

Do we need to install or host anything?
No. The adapter runs entirely in the Graphite cloud. Your setup consists of the integration user (and optionally an OAuth client) described in Setup.

Do we need to open firewall ports or set up a VPN?
No, provided your Oracle Fusion REST endpoint is reachable over HTTPS. The adapter calls the same public REST API surface Oracle provides for all integrations. If your security policy restricts API access by source IP, Graphite's requests originate from a fixed set of egress IP addresses that you can allowlist — ask your Graphite integration contact for the current list.

Does the adapter bypass Oracle validations or security?
No. All writes go through Oracle's standard REST resources and execute as the integration user, limited to the roles you assign. Oracle's validations, duplicate checks, and approval rules apply to every change.

What user do changes run as?
With Basic authentication, the dedicated integration user. With OAuth, the user who authorized the connection — which is why the one-time authorization should be performed as the integration user.

How does it avoid creating duplicate suppliers or banks?
Through layered matching (stored IDs, supplier number, tax identifiers, name) and a strict rule: when multiple potential matches exist, the adapter reports an error for human review instead of creating a record. See Supplier Matching & Duplicate Prevention.

Does it support Oracle-assigned supplier numbers?
Yes. When the adapter creates a supplier, it captures the Supplier ID and supplier number Oracle assigns and writes them back to the supplier's Graphite profile.

Why isn't site data syncing for a supplier?
Supplier sites, payees, payment methods, and bank accounts are only synchronized once the supplier's business relationship is Spend Authorized. The adapter can submit the spend authorization request automatically if configured — see Spend authorization auto-approval.

Can a site's address be changed after creation?
Oracle does not allow changing the address linked to an existing site through the REST API. Address changes are applied to the address record itself; the site continues to reference it.

How fresh is the data?
The adapter processes supplier changes shortly after they are approved in Graphite, on a polling cycle configured per customer.