Oracle JD Edwards and Procurify integration

What moves between them

The integration polls Oracle JD Edwards purchase order headers and details on a schedule you define, then creates corresponding requisitions and purchase orders in Procurify. Supplier records from JD Edwards F0401 are synced to Procurify vendors, and GL accounts from JD Edwards F0901 are mapped to Procurify account codes so spend allocations match your chart of accounts. Separately, the integration polls Procurify bills and payments, then posts them as accounts payable batches into JD Edwards F0411Z1 (Journal Entry batch) so the GL stays current with Procurify invoice and payment activity. The direction is bidirectional for reference data (suppliers and GL accounts synced both ways) and separate for transactional flow: orders JD Edwards to Procurify, bills Procurify to JD Edwards. All syncs use polling, since JD Edwards has no webhook support.

How ml-connector handles it

ml-connector stores the AIS Server hostname, port, and credentials securely, and obtains a session token before each batch of queries; if the token expires during a session (HTTP 444 response), it re-authenticates without losing the batch. For Procurify, it uses the customer domain and OAuth client credentials to get a 24-hour Bearer token, refreshed as needed. Purchase order mapping is direct: JD Edwards F4301 (header) and F4311 (detail lines) become Procurify purchase orders with items allocated to the mapped account codes. Supplier F0401 records map to Procurify vendors by synchronizing name, status, and contact info. On the return path, Procurify bills are read with a date-range filter, then posted into JD Edwards via F0911Z1 (Account Ledger batch) using a batch orchestration or form service, because direct F-table writes are not supported. GL accounts from JD Edwards F0901 are read once and cached to populate Procurify account code selection during bill import. Rate limits are practical (AIS Server JVM and thread pool) rather than documented; if Procurify timeouts occur, the integration backs off and retries. Every record carries a full audit trail showing source entity ID, target entity ID, timestamp, and any mapping mismatch (e.g., supplier in JD Edwards but no match in Procurify). Since neither system has signed push events, polling is time-based: check UPMJ (JD Edwards) and last_modified (Procurify) every 1 to 4 hours depending on your volume.

A real-world example

A mid-sized manufacturing company runs Oracle JD Edwards on premises for operations and finance, and recently deployed Procurify to centralize procurement and improve spend visibility. Before the integration, the procurement team entered purchase orders from JD Edwards into Procurify manually, and accountants in JD Edwards waited for Procurify bill exports before posting them to the ledger. Reconciliation between the two was fragile, with order quantities changing in one system without visibility in the other. With Oracle JD Edwards and Procurify connected, purchase orders from JD Edwards appear automatically in Procurify with correct account codes, and Procurify bills flow back to JD Edwards GL postings without re-keying. The procurement team now has a single source of truth for orders and spend, and the accounting team posts bills on schedule with no manual entry.

What you can do

• •Sync purchase orders from Oracle JD Edwards to Procurify requisitions and purchase orders with correct account code mappings.
• •Keep supplier records synchronized between JD Edwards F0401 (Supplier Master) and Procurify vendors.
• •Poll Procurify bills and post them as accounts payable batches into Oracle JD Edwards GL journal entries.
• •Handle Oracle JD Edwards session token authentication (30- to 60-minute refresh) and Procurify OAuth 2.0 client credentials (24-hour refresh) on every request.
• •Track all record syncs with full audit trail, including source and target entity IDs, and replay failed bills or orders on demand.

Questions

Which direction do purchase orders and bills move between Oracle JD Edwards and Procurify?

Purchase orders flow from JD Edwards into Procurify, so your Procurify system has visibility into orders created in JD Edwards. Bills and payments flow from Procurify back into JD Edwards for GL posting and reconciliation. Supplier and GL account data sync bidirectionally to keep both systems aligned.

How does ml-connector handle the 30-minute session token timeout in Oracle JD Edwards?

ml-connector obtains a new session token via POST to the AIS Server /jderest/v2/tokenrequest endpoint before starting each batch of queries. If a token expires mid-request (HTTP 444 response), it re-authenticates and retries the batch. Tokens are tied to the service account user, so the account must hold an active JD Edwards license.

What happens if a Procurify bill cannot be posted into Oracle JD Edwards GL because the account code does not exist?

Every bill sync attempt is logged with the full audit trail including the reason for failure (e.g., account code 4000-0-0-0 not found in F0901). ml-connector stores the bill in a retry queue and can replay the post once the missing account is created in JD Edwards, so no bills are lost.