Oracle JD Edwards and Tradeshift integration

What moves between them

Purchase orders flow from JD Edwards into Tradeshift, where suppliers view and acknowledge them. Invoices created in Tradeshift by suppliers flow back into JD Edwards AP matching, where they are matched to POs and receipts. Vendor records from JD Edwards Address Book and Supplier Master are synced to Tradeshift company profiles so the network sees the correct buyer identity. The main cycle is pull from JD Edwards PO, push to Tradeshift, poll Tradeshift for new invoices, push those back to JD Edwards AP Ledger. All syncs happen on a schedule you define, typically after business hours or on a daily cadence.

How ml-connector handles it

ml-connector stores JD Edwards credentials (username, password, AIS Server URL) and Tradeshift OAuth 1.0a credentials (consumer key, secret, token, token secret) encrypted at rest. On each cycle, it obtains a fresh JD Edwards session token, queries the F4301/F4311 PO tables with a date filter, and maps the PO headers and line items to Tradeshift UBL document format. It then polls Tradeshift documents/v2 with the changedAfter timestamp to fetch new invoices, translates the UBL XML back to JD Edwards field format, and writes matched invoices to the F0411 AP Ledger using the batch voucher orchestration path. All 429 rate-limit responses from Tradeshift trigger exponential backoff and retry. Vendor address book records are matched by supplier code, and unmatched records are flagged for manual review. Every document movement carries a full audit trail with the source document ID, timestamp, and any transformation notes.

A real-world example

A mid-sized manufacturing company uses JD Edwards on premises for procurement and accounting across three divisions. Before the integration, buyers entered purchase orders in JD Edwards, printed them, emailed them to suppliers, and suppliers responded with paper or email invoices that the accounts payable team re-entered into JD Edwards for 3-way matching. With Oracle JD Edwards and Tradeshift connected, purchase orders flow directly from JD Edwards into Tradeshift, suppliers submit invoices through the Tradeshift network, and matched invoices post directly into JD Edwards AP. The AP team no longer handles paper, manual entry is eliminated, and invoice-to-cash cycles shorten because early payment discounts can be taken without delay.

What you can do

• •Push JD Edwards purchase orders into Tradeshift so suppliers can view, acknowledge, and submit matched invoices.
• •Pull invoices from Tradeshift back into JD Edwards AP Ledger for 3-way matching against POs and receipts.
• •Sync vendor records from JD Edwards Supplier Master to Tradeshift company profiles for accurate buyer identity and network connections.
• •Handle OAuth 1.0a session token refresh, AIS Server session token refresh, and UBL document format translation automatically.
• •Provide a full audit trail on every PO and invoice movement with source document IDs, transformation details, and timestamps.

Questions

Does Oracle JD Edwards need to be on the cloud, or does this work with on-premises deployments?

ml-connector works with on-premises JD Edwards EnterpriseOne only. It requires a customer-hosted Application Interface Services (AIS) Server with REST endpoints enabled. The customer provides the full AIS Server URL (including port) and credentials; no public cloud hostname is required. Cloud JD Edwards (if available) would use a different authentication path and has not been validated.

How does the integration handle the UBL XML format that Tradeshift uses?

ml-connector translates JD Edwards purchase orders (F4301/F4311 tables) into UBL 2.0 format for Tradeshift and parses incoming Tradeshift invoices back into JD Edwards AP field structures. The UBL documents carry all line-item detail, tax, and dimensions in XML tags; ml-connector extracts and maps these to the matching JD Edwards GL accounts and cost centers based on the PO line reference.

What happens if a JD Edwards session token expires during a sync?

ml-connector detects HTTP 444 responses (invalid token) and immediately requests a fresh token via POST to /jderest/v2/tokenrequest. The sync resumes with the new token. If rate limits or network delays cause the token to expire between PO fetch and AP write, the operation is rolled back and retried on the next scheduled cycle with fresh credentials for both systems.